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ABSTRACT 


Tbit  thesis  pretests  a  database  application,  the  Republic  of  Korea  military 
pffryytyyj  management  system.  In  order  to  maximize  the  utilization  of  personnel 
resource*  a  computerized  personnel  information  system  is  needed. 

An  important  consideration  in  database  design  is  to  assure  that  data  can  be  used 
for  a  wide  variety  of  applications  and  can  be  changed  quickly  and  independently.  For 
thir  purpose,  we  discuss  normal  forms  including  functional  dependency  concepts. 

A  ample  data  base  using  dBASE  III  +  is  implemented  on  an  IBM  PC.  It  is 
for  the  user  who  does  not  have  computer  experience,  and  is  based  on  the 
theoretical  design  problems. 
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L  INTRODUCTION 


TIm  influence  of  personnel  management  on  the  business  organization  has 
increased  appreciably  in  recent  years.  Much  of  this  increase  can  be  attributed  to  the 
growing  complexity  of  human  resource  management  and  the  issues  related  to  it  In  the 
Republic  of  Korea(R.O.K),  in  order  to  strengthen  the  capability  of  combat  under  the 
limited  national  defense  expenditure,  it  is  imperative  that  personnel  management  be 
performed  very  efficiently.  To  achieve  this  goal,  the  high  level  managers  of  the  military 
very  often  need  a  variety  of  data  relevant  to  each  person.  Therefore,  a  modem 
database  management  system  is  needed  for  the  R.O.K  military  personnel  management 
system. 

The  database  management  systems  now  in  use  permit  greater  flexibility  in 
meeting  information  requirements,  faster  response  times,  and  easier  user  access  to 
stored  data  then  earlier  software  systems.  These  benefits  are  achieved  at  the  expense  of 
larger  capital  and  manpower  investments,  greater  system  complexity,  lower  processing 
efficiency,  and  long  pay  off  periods.  The  value  of  such  systems  can  not  be  determined 
strictly  on  money,  but  also  by  the  increase  in  the  number  of  applications  processed  for 
noncomputer  oriented  users.  Perhaps  the  most  exciting  development  to  occur  from  the 
introduction  of  such  systems  is  the  wide  availability  of  easy  to  use  query  type 
languages  which  permit  nonprogrammers  to  create,  update,  maintain,  and  extract 
information  from  their  own  flies. 

In  database  development,  it  should  be  possible  to  query  the  database  to  satisfy 
the  user's  requirements  using  application  programs  or  the  Database  Management 
System(DBMS)  itself.  Because  there  are  many  types  of  data  structures,  models,  designs 
etc.,  we  should  select  one  which  depends  on  the  problem  or  situation.  The  normal 
form  concepts  of  relational  database  models  will  be  applied  to  develop  a  database  for 
the  Korean  military  personnel  management.  Most  experts  agree  that  the  relational 
data  model  supports  data  independence  better  than  other  models. 

This  thesis  will  focus  on  a  database  design  applying  a  Relational  Model  to  R.O.K 
Army  and  Air  Force  personnel  management.  The  actual  sample  data  of  R.O.K  Army 
personnel  will  be  used  for  implementing  the  sample  program  using  dBASE  III  +  .  In 
Chapter  II,  Background,  we  will  address  personnel  management  and  give  a  general 
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aurtwr  of  a  database  system.  In  Chapter  III,  general  concept  of  the  Relational 
Model  wBl  be  discussed  and  in  Chapter  IV,  data  base  design  problems  will  be  discussed 
hi  detail  theoretically.  In  Chapter  V,  practical  system  analysis  and  relational  database 
design  for  Korean  Army  personnel  management  system  will  be  discussed.  In  Chapter 
we  will  discuss  and  show  example  for  data  base  implementation  and  in  Chapter 
,  processing  procedure  to  access  the  sample  program  in  Appendix  A  will  be  shown. 
Chapter  VIII,  conclusions  will  be  drawn  and  recommendations  for  implementation 
be  offered. 


IL  BACKGROUND 


A  PERSONNEL  MANAGEMENT 

1.  Bask  concept 

To  meet  organizational  effectives  it  is  necessary  to  continually  acquire  human 
resources;  integrate  employees  into  the  organization;  develop  employee  potential;  and 
maintain  the  work  force.  Personnel  management  is  an  integral  part  of  the  broader  field 
of  management.  Management  has  been  defined  as  the  process  of  accomplishing 
objectives  through  the  efforts  of  other  people  within  an  organization.  Thus,  we  can 
say  that  the  role  of  personnel  is  critical  for  managing  in  general.  [Ref.  1:  p.  17) 

In  any  military  hierarchy  there  are  many  levels  of  command  and  control.  Each  level 
has  its  own  duties  and  needs  adequate  number  of  people  with-  respect  to  knowledge, 
capability,  rank,  skill  etc 

2.  Objectives. 

.  Objectives  are  the*  starting  point  of  the  management  process.  They  give  the 
organization  and*  its  people  a  purpose  and  direction.  Objectives  serve  to  guide 
managers  and  employees  in  their  efforts.  The  managers  commonly  perform  these 
functions: 

(1)  Plqnrufl|^-  determining  strategies  and  programs  to  help  accomplish  established 

(2)  Organising  -  growing  and  assigning  .activities,  staffing  the  organization,  and 
delegating  authority  to  carry  out  activities. 

(3)  Directing  •  encouraging  human  efforts  and  stimulating  accomplishment  of 
objectives. 

(4)  Controlling  -  measuring  accomplishments,  comparing  results  with  planned 
objectives,  determining  causes  of  deviations,  and  taking  necessary  corrective 
action. 

3.  Korean  Army  and  Air  Force  personnel  management 

The  Republic  of  Korea's(R.O.K)  Army  and  Air  Force  uses  the  general  staff 
model  which  includes  Personnel,  Intelligence,  Operations  and  Training,  and 
Logistics(Gl-G4).  The  R.O.K  government  spends  a  large  percentage  of  the  total 
government  budget  for  national  defense  and  the  Department  of  National  Defense 
spends  a  significant  portion  of  the  national  defense  expenditures  for  personnel. 

Personnel  managers  need  data  about  the  individual  personnel  capability  and 
group  personnel  capability  to  analyze,  to  investigate,  to  plan,  and  to  apply  this  data  for 


Arir  organizations.  Information  about  group  personnel  power  can  be  derived  by  a 
collection  of  individual  personnel  power.  It  is  important  to  increase  individual  and 
group  personnel  power  in  the  personnel  management  field  so  that  the  right  people 
move  into  the  right,  jobs  at  the  right  times  and  under  the  right  circumstances. 
[Ref.  2:  p.73] 

In  the  military,  information  about  individual  personnel  power  can  be  derived 
from  functions  involving  procurement,  education  and  training,  assignment,  treatment, 
promotion  and  retirement.  In  order  to  reduce  the  national  defense  expenditure  and 
increase  the  war_making  capability,  the  Korean  military  needs  a  computerized 
management  information  system  personnel  management.  Therefore,  some  important 
functions  of  the  Army  and  Air  Force's  Department  of  Personnel  Management  and 
other  essential  information  are  analyzed  as  system  requirements.  Information 
management  by  computer  is  very  important  for  fast  and  accurate  personnel 
management  in  the  Korean  military. 

B.  DATA  VERSUS  INFORMATION 

Data  and  information  are  meant  to  have  two  distinct  meanings.  Data  may  best 
be  thought  of  as  representing  objective,  external  realities  such  as  a  flash  of  lightning  in 
the  sky,  the  expression  on  an  employee's  face,  or  the  number  of  widgets  produced  per 
day  on  the  production  line.  Viewed  in  this  way,  data  becomes  pure  fact.  Data  is 
knowledge  for  the  sake  of  knowledge.  When  captured  and  stored,  data  is  merely  a 
record  of  these  specific  characteristics  and  events  which  can  be  reliably  observed  and 
which  have  sufficient  impact  to  be  taken  note  of. 

On  the  other  hand,  the  term  'information'  may  be  restricted  to  mean  interpreted 
data.  Information  should  be  thought  of  as  the  statement  of  the  relationship  of  any 
given  characteristic  or  event  to  specific  goals  and  purposes.  It  is  what  is  used  to 
control  progress  toward  these  goals  and  objectives.  The  term  'information'  will  be 
reserved  to  mean  knowledge  for  the  sake  of  purposeful  action.  These  are  the  key 
definitions: 


Rata  is  ^he  record  of  any  reliably  observable  characteristic  or  event  m  nature. 

(formation  is  the  description  of  the  relationship  of  anv  such  characteristic  or 
event  to  human  goals  and,' or  business  purposes  [Ref.  3:  p.124]. 


Figure  2.1  shows  this  relationship. 
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Figure  2.1  Data  versus  Information. 

C  GENERAL  OVERVIEW  OF  A  DATABASE  SYSTEM 
L  Introduction 

The  theory  of  data  management  predates  computers.  Early  attempts  at 
putting  the  theory  into  practice  with  rudimentary  equipment  were  made  in  the  1940s 
and  early  1950s.  Computers  were  applied  to  the  management  of  data  in  late  1950s  and 
early  1960s.  These  computers  were  able  to  process  data  more  quickly  and  in  greater 
quantities  than  ever  before,  but  the  management  of  data  (storage,  manipulation  and 
retrieval)  was  still  quite  unsophisticated.  The  architecture  of  computers  at  that  time 
facilitated  sequential  processing  of  large  volumes  of  data  or  massive  computations 
made  on  small  amount  of  data,  one  job  at  a  time.  In  the  middle  1960s,  computer 
architecture  was  radically  changed.  A  quantum  increase  in  the  size  of  computer 
memory  and  the  introduction  of  operating  systems  made  it  possible  for  computers  to 
do  more  than  one  job  concurrently.  This  kind  of  processing  called  multi-programming, 
has  continued  right  up  to  the  present. 

Concurrent  with  multi-programming  came  the  capacity  to  do  what  is  called 
'on-line'  or  single  transaction  processing.  Rather  than  process  large  volumes  of  data 
sequentially,  it  has  become  economically  feasible  to  access  specific  information  from 
computer  stored  files  within  seconds.  In  the  late  1960s,  more  sophisticated  methods  of 
storing  and  retrieving  data  were  incorporated  into  computer  software  (programs). 
These  programs  were  the  first  data  base  management  systems.  The  idea  was  just  a 
little  ahead  of  its  time.  Although  computer  memories  had  grown  in  size  from 
thousands  of  positions  to  hundreds  of  thousands,  they  were  not  quite  up  to  the  task. 
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Hawwg,  in  the  early  and  middle  1970*,  computer  memory  capacities  were  such  that 
ndffions  of  characters  could  be  stored  in  them,  and  storage  technology  had  increased 
the  potential  size  even  Anther.  This  increase  has  made  possible  the  implementation  of 
data  management  software.  Since  it  has  become  technologically  possible  (and  is  at 
least  approaching  economic  feasibility),  the  concept  of  data  management  is  now 
emerging  in  the  business  community.  Technological  advances  are  making  it  possible  to 
store  data  in  a  way  that  is  radically  different  from  most  of  the  contemporary  methods 
now  in  use.  This  new  technology  is  manifesting  itself  in  both  hardware  and  software. 
Hardware  technology  is  allowing  for  large  amounts  of  data  (billions  of  characters)  to 
be  stored  on-line.  Software  technology  is  supplying  the  mechanisms  for  the  storing, 
updating  and  retrieving  of  that  data. 

The  mechanisms  for  manipulating  and  retrieving  data  (converting  data  to 
information)  are  known  as  Data  Base  Management  Systems(DBMS).  There  are  a 
number  of  software  packages  that  provide  these  mechanisms.  [Ref.  4:  p.ll] 

2.  Data  base  system  definitions 

Data  base  terminology  and  data  base  theory  will  be  briefly  presented  in  this 
section.  To  facilitate  this  discussion,  it  is  necessary  to  set  some  common  definitions. 
They  are: 

(1)  Data  is  a  group  of  non-random  symbols  that  represent  quantities,  actions, 
things,  facts,  concepts  or  instructions  m  a  way  suitable  for  communication  and 
processing  by  humans  or  machines.  Information  is  data  that  has  been 
processed^ and  presented,  as  described  in  B.  in  this  chapter. 

(2)  A  record  is  a  group  of  related  data  items. 

(3)  A  file  (data  set)  is  a  collection  of  related  records.  A  database  is  a  collection  of 
files  logically  related  in  such  a  way  as  to  improve  access  to  the  data  and 
minimize  redundancy  of  data. 

(4)  A  data  base  management  system  is  a  set  of  programs  that  function  to  create 
and  update  the  data  base,  retrieve  data  ana  generate  reports  from  the  data 
base.  A  conceptual  model  (data  model)  is  a  representation  of  the  information 
content  of  the  data  base.  Figure  2.2  shows  the  composition  of  data  base. 

3.  What  is  DBMS? 

In  simple  terms,  it  is  a  computer  software  system  that  provides  control, 
retrieval  and  storage  of  data  contained  in  one  or  a  combination  of  data  files  that  are 
tied  together  by  the  DBMS  and  are  more  commonly  referred  to  as  a  data  base. 
Provided  by  the  computer  manufacturer  or  an  independent  software  house,  the 
software  package  is  adaptable  to  all  application  systems.  But  DBMS  can  be  truly 
understood  by  contrasting  it  with  traditional  practices. 

The  ordinary  systems  development  approach  has  been  to  organize  data  into 
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Figure  2.2  Composition  of  database1. 

individual  files,  with  the  typical  business  data  processing  center  developing  around  the 
computerization  of  separate  applications  such  as  payroll,  inventory,  and  accounts 
receivable.  What  happens,  however,  is  that  the  computer  data  files  necessary  to 
support  these  applications  are  fixed  in  their  structure  with  preset  formats  frozen  into 
the  computer  programs.  The  result  has  been  that  when  a  range  of  data  values  has 
grown  to  the  point  where,  let  us  say,  one  more  digit  position  is  required,  there  may  be 


»  physical  space  in  the  (tie  record.  The  entire  computerized  data  record 
either  be  expanded  or  redesigned,  and  this  new  design  in  turn  leads  to 
I0ss  hi  ail  computer  programs  that  use  these  computer  data  files. 


Figure  2.3  Example  of  File  Processing  Systemsf  pre-database)  . 

James  Martin,  a  well  known  author  in  the  data  base  field,  defined  a  data  base 


a  collection  of  interrelated  data  stored  together  without  unneces*....,  _ 

to  serve  multiple  applications.  The  data  are  stored  so  that  they  are  independc 
of  tpe  programs  which  use  thpm.  A  common  and  controlled  approach  is  used 
adding  new  data  and  modifying  and  retrieving  existing  data.  The  data  ; 
^uptyred  jo  as  to  provide  a  foundation  for  future  applicatir  J"“’ - 
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vithout  unnecessary  redundancy 
ed  so  that  they  are  independent 
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Figure  2.3  and  Figure  2.4  show  the  characteristics  of  database  processing  system. 


,  2  Kroenke.  David  Database  Processing :  Fundamentals ,  Design,  Implementation, 

Science  Research  Associates  INC,  1983,  p.2 


The  current  science  dearly  demands  an  environment  that  is  quite  different  and 
ftatuves  flexibility  and  expandability  -  inherent  features  hi  a  data  base  management 
system.  Specifically,  DBMS  possesses  the  following  characteristics: 

1)  the^structuring  pf  datp  bases  and  control  of  the 


Figure  2.4  Example  of  Data  Base  Processing  Systenr . 
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Data  independence.  A  seemingly  trivial  application  design  change  or  database 
expansion  can  have  an  undesirable  cost  impact.  Hence,  it  js  important  to 
avoid  dependence  or  computer  programs  on  a  fixed  physical  data  base. 
DBMS  permits  the  addition  ?nd  deletion  of  the  data  base,  data  fields  or  data 
records  without  modifying  existing  computer  programs. 


Control  of  data  redundancy,  proliferation  of  similar  data  as  more  and  more 
data  bases  are  integrated.  While  not  eliminating  all  Redundancy,  DBMS 
avoids  much  of  this  oy  structuring  conunon  data  needs  is  terms  of  so-called 
logical  data  relationships  that  avoid  duplicate  data  values. 


^Kroenke,  David  M.,  Database  Processing :  Fundamentals,  Design,  Implementation, 
Science  Research  Associates  INC.,  1983,  p.4 
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well  as  off-promise  storage  for  back  up  purposes. 

Database  technology  allows  an  organization's  data  to  be  processed  as  an 
integrated  whole.  It  reduces  artificiality  imposed  by  separate  files  for  separate 
applications  and  permits  users  to  access  data  more  naturally.  Data  integration  offers 
several  important  advantages: 

•  More  information  from  the  same  amount  of  data 

•  New  reports  and  one-a-kind  requests  more  easily  implemented 

•  Elimination  of  data  duplication 

•  Program7  Data  independence 

•  Better  data  management 

•  Affordable,sophisticated  programming 

•  Representation  of  record  relationships 


On  the  other  hand,  database  processing  has  a  few  disadvantages: 

•  Expensive  database  management  system 

•  Higher  operating  cost 

•  Complexity 

•  Recovery  is  more  difficult 

•  Increased  vulnerability  to  failure 
5.  Levels  of  abstraction  in  a  DBMS 

A  fairly  standard  viewpoint  regarding  levels  of  abstraction  is  shown  in  Figure 
2.5.  [Ref.  6:  p.3]  There  we  see  a  single  database,  which  may  be  one  of  many  databases 
using  the  same  DBMS  software,  at  three  different  levels  of  abstraction.  The 
conceptual  database  is  an  abstract  representation  of  the  physical  database  (or, 
equivalently,  we  may  say  the  physical  database  is  an  implementation  of  the  conceptual 
database),  and  the  views  are  each  abstraction  of  portions  of  the  conceptual  database. 
The  difference  in  the  level  of  abstraction  between  views  and  the  conceptual  database  is 
generally  not  great. 

The  term  scheme  is  used  to  refer  to  plans,  so  we  talk  of  a  conceptual  scheme 
as  the  plan  for  the  conceptual  database,  and  we  call  the  physical  database  plan  a 
physical  scheme.  The  plan  for  a  view  is  often  referred  to  simply  as  a  subscheme. 
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Figure  2.5  Levels  of  Abstraction  in  A  Database  System4. 

As  we  have  said,  the  conceptual  scheme  is  an  abstraction  of  the  real  world 
pertinent  to  an.  organization  like  enterprise.  A  DBMS  provides  a  data  definition 
language  to  specify  the  conceptual  scheme  and,  most  likely,  some  of  the  details 
regarding  the  implementation  of  the  conceptual  scheme  by  the  physical  scheme.  The 
data  definition  language  is  a  high-level  language,  enabling  one  to  describe  the 
conceptual  scheme  in  terms  of  a  "data  model'. 
b.  Views 

A  view  or  subscheme  is  an  abstract  model  of  a  portion  of  the  conceptual 
database  or  conceptual  scheme.  For  example,  an  airline  may  provide  a  computerized 
reservation  service,  consisting  of  data  and  a  collection  of  programs  that  deal  with 
flights  and  passengers.  These  programs,  and  the  people  who  use  them,  do  not  need  to 
know  about  personnel  files  or  the  assignment  of  pitots  to  flights.  The  dispatcher  may 
need  to  know  about  flights,  aircraft,  and  aspects  of  the  personnel  files  (e.g.,  which 
pilots  are  qualified  to  fly  a  747),  but  does  not  need  to  know  about  personnel  salaries  or 
the  passengers  booked  on  a  flight. 


^  4UUman,  Jeffery  D.,  Principles  of  database  system.  Computer  Science  Press  INC., 

1980,  p.3 
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At  the  forest  ford  of  abstraction  with  which  we  deal,  there  is  a  physical 
database.  The  physical  database  resides  permanently  on  secondary  storage  devices, 
such  as  disks  and  tapes.  We  may  view  the  physical  database  itself  at  several  levels  of 
abstraction,  ranging  from  that  of  records  and  files  in  a  programming  language  such  as 
PL/I,  perhaps  through  the  level  of  logical  records,  as  supported  by  the  operating 
system  undertying  the  DBMS,  down  to  the  level  of  bits  and  physical  addresses  on 
storage  devices. 

6.  The  objectives  of  database  system  organizations 

A  database  system  should  be  the  repository  of  the  data  needed  for  an 
organization's  data  processing.  That  data  should  be  accurate,  private,  and  protected 
from  damage.  The  system  should  be  designed  so  that  diverse  applications  with 
different  data/information  requirements  can  employ  the  data.  Different  end-users  have 
different  views  of  data  which  should  be  derived  from  a  common  overall  data  structure. 
In  order  to  achieve  these  user  requirements  and  others,  the  following  objectives  are 
considered  by  database  system  designers.  [Ref.  7:  p.34] 

(1)  The  database  THE  FOUNDATION  OF  FUTURE  APPLICATION 
DEVELOPMENT.  It  should  make  application  development  easier,  cheaper, 
faster,  and  more  flexible. 


(2)  THE  DATA 
the  same  data 


N  HAVE  MULTIPLE  USES.  Different  users  who  perceive 
erently  can  employ  them  in  different  ways. 


(3) 


CLARITY.  .Users  can  easily  determine  and  understand  what  data  are 
available  to  them. 


(4)  EASE.  OF  .USE.  Users  can  gain  access  to  data  in  a  simple  fashion. 
Complexity  is  hidden  from  the  users  by  the  DBMS. 

(5)  FLEXIBLE  USAGE.  The  data  can  be  used  or  searched  in  several  ways  with 
different  access  paths. 

(6)  CHANGE. IS  EASY.  The  database  can  grow  and  change  without  interfering 
with  established  procedures  tor  using  the  data. 

(7)  LOW  COST.  The  cost  of  storing  and  using  data,  and  the  cost  of  making 
changes,  must  be  as  small  as  possiole. 

(8)  LESS  DATA  PROLIFERATION.  New  application  needs  may  be  met  with 
existing  data  rather  than  creating  new  fires,  thus  avoiding  the  excessive 
proliferation  in  today  s  tape  libraries. 

(9)  PERFORMANCE.  Data  requests  can  be  satisfied  with  speed  suitable  to  the 
usage  of  the  data. 

(10)  PRIVACY.  Unauthorized  awess  to  the  data  will  be  prevented.  The  same 
data  should  be  restricted  in  different  ways  from  different  uses. 

(11)  AVAILABILITY.  Data  should  be  available  to  users  at  the  time  when  thev 
need  them. 


(12)  RELIABILITY.  Almost  all  information/ data  for  personnel  management  is 
very  important  to  both  individual  personnel  (e.g.  for  promotion,  for  new 
assignment,  etc.)  and  group  personnel.  The  information  which  is  denved  from 
database  processing  must  oe  very  reliable. 

D..  DATABASE  MODEL 

A  data  model  is  a  collection  of  data  structures  together  with  a  collection  of 
operations  that  manipulate  the  data  structures  for  the  purpose  of  storing,  querying,  or 
processing  the  structure  contents.  A  data  model  may  also  include  the  integrity 
constraints  defined  over  the  data  structures,  or  it  may  include  access  control  facilities 
of  mechanisms  for  defining  various  external  user  views  of  the  database.  Some  data 
models  provide  physical  storage  structures  and  physical  access  methods  as  part  of  the 
data  model,  but  usually  a  data  model  is  limited  to  the  data  structures  and  operations 
that  are  available  to  an  end  user  and  may  be  accessed  from  an  application  program. 
There  are  two  reasons  for  studying  database  models.  First,  they  are  an  important 
database  design  tool.  Database  models  can  be  used  for  both  logical  and  physical 
database  design  -  much  as  flow  charts  or  pseudocode  are  used  for  program  design. 
Second,  database  models  are  used  to  categorize  DBMS  products.  In  this  section,  we 
will  discuss  the  components  of  a  database  model  and  survey  six  important  models. 

1.  Component  of  database  model 

Database  models  have  two  major  components.  The  Data  Definition 
Language  (DDL)  is  a  vocabulary  for  defining  the  structure  of  the  database.  The  DDL 
must  include  terms  for  defining  records,  fields,  keys,  and  relationships.  In  addition  the 
DDL  should  provide  a  facility  for  expressing  database  constraints.  Data  Manipulation 
Language  (DML)  is  the  second  component  of  a  database  model.  The  DML  is  a 
vocabulary  for  describing  the  processing  of  the  database.  Facilities  are  needed  to 
retrieve  and  change  database  data.  There  are  two  types  of  DML,  procedural  DML 
and  nonprocedural  DML.  Procedural  DML  is  a  language  for  describing  actions  to  be 
performed  on  the  database.  Procedural  DML  obtains  a  described  result  by  specifying 
operations  to  be  performed.  For  procedural  DML,  facilities  are  needed  to  define  the 
data  to  be  operated  on  and  to  express  the  actions  to  be  taken.  Both  data  items  and 
relationships  can  be  accessed  or  modified.  Nonprocedural  DML  is  a  language  for 
describing  the  data  that  is  wanted  without  describing  how  to  obtain  it. 

2.  Prominent  database  models. 

Figure  2.6  portrays  six  common  and  useful  database  models.  Models  on  the 
left-hand  side  of  this  figure  tend  to  be  oriented  to  humans  and  human  meaning, 
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Figure  2.6  Relationship  of  Six  Important  Data  Models. 

a.  Relational  data  model 

The  relational  database  model  is  near  the  midpoint  of  the  human/machine 
continuum  in  Figure  2.9,  because  it  has  both  logical  and  physical  characteristics.  The 
relational  model  is  logical  in  that  data  are  represented  in  a  format  familiar  to  humans; 
the  relational  model  is  unconcerned  with  how  the  data  are  represented  in  computer 
files.  On  the  other  hand,  this  is  more  physical  than  SDM(semantic  data  model)  or  the 
E_R(entity  relationship)  model.  Database  that  have  been  designed  according  to  the 
relational  need  not  be  transformed  into  some  other  format  before  implementation. 
Thus  the  relational  model  can  be  used  for  both  logical  and  physical  database  design.  A 
relation  is  simply  a  flat  file.  The  rows  of  the  relation  are  the  file  records.  Rows  are 
sometimes  called  tuples  of  the  relation.  The  field  of  the  relation  (in  the  columns)  are 
sometimes  called  the  attributes  of  the  relation.  The  significance  of  the  relational  model 
is  not  that  data  are  arranged  in  relations  but  that  relationships  are  concerned  to  be 
implied  by  data  values.  The  principle  advantage  of  carrying  relationships  in  data  is 
flexibility.  Relationships  need  not  be  predefined.  (Ref.  7:  p.  196) 

b.  Semantic  data  model 

The  word  semantic  means  meaning.  The  semantic  data  model  provides  a 
vocabulary  for  expressing  the  meaning  as  well  as  the  structure  of  database  data.  As 
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each,  SDM  it  useftt  for  logical  database  design  and  documentation.  SDM  provides  a 
precise  documentation  and  communication  medium  for  database  users.  In  particular,  a 
new  user  of  a  large  and  complex  database  should  find  its  SDM  schema  of  use  in 
determining  what  information  is  contained  in  the  database.  Also,  SDM  provides  the 
basis  for  a  variety  of  high  level  semantics- based  user  interfaces  to  a  database.  SDM 
has  been  designed  to  satisfy  a  number  of  criteria  that  are  not  met  by  contemporary 
database  models.  The  chief  advantage  of  SDM  is  that  it  provides  a  facility  for 
expressing  meaning  about  the  data  in  the  database.  Another  advantage  of  SDM  is 
that  it  allows  data  to  be  described  in  context.  Users  see  data  from  different 
perspectives.  They  see  it  relative  to  their  field  of  operation.  SDM  allows  relative  data 
definition.  A  third  advantage  of  SDM  is  that  constraints  on  database  data  can  be 
defined.  For  example,  if  a  given  item  is  not  changeable,  SDM  allows  this  fact  to  be 
stated.  With  other  data  models,  such  constraints  are  not  part  of  the  schema 
description  and  are  documented  separately.  SDM  is  like  a  pseudocode.  But,instead  of 
describing  the  structure  of  programs  as  pseudocode  does.SDM  describes  the  structure 
of  data.  Like  pseudocode,  SDM  has  certain  structures  and  rules,  and  within  those 
structures  and  rules,  the  designer  has  a  good  deal  of  latitude  and  flexibility. 
[Ref.  7:  p.193] 

c.  Entity  -  Relationship  model 

The  entity-  relationship  model(E-R  model)  is  primarily  a  logical  database 
model,  although  it  has  some  aspects  of  a  physical  model  as  well  As  its  name  implies, 
the  E-R  model  is  explicit  about  relationship.  Unlike  SDM,  in  the  E-R  model  both 
entities  and  relationships  are  considered  to  be  different  constructs.  Entities  are 
grouped  into  entity  sets,  and  relationships  are  grouped  into  relationship  sets.  An 
entity-relationship  diagram  is  a  graphical  portrayal  of  entities  and  their  relationships. 
It  is  useful  to  summarize  the  information  in  a  design.  It  supports  the  representation  of 
more  general  relationships.  [Ref.  7:  p.  1 94] 

d.  CODASYL  DBTG  model 

The  CODASYL  DBTG(  conference  on  Data  System  Languages,  Database 
Task  Group)  data  model  was  developed  by  the  same  group  that  formulated  COBOL 
during  the  late  1960s  and  is  the  oldest  of  the  data  models.  The  DBTG  model  is  a 
physical  database  model.  There  are  constructs  for  defining  physical  characteristics  of 
data,  for  describing  where  data  should  be  located,  for  instructing  the  DBMS  regarding 
what  data  structures  to  use  for  implementing  record  relationships,  and  other  similar 


27 


physical  characteristics.  A  DBTG  schema  is  the  collection  of  all  records  and 
relationships.  A  subschema  is  a  subset  and  reordering  of  records  and  relationships  in 
the  schema.  Unlike  the  relational  model,  relationships  become  fixed  when  they  are 
defined  in  the  schema.  Several  reasons  account  for  the  lukewarm  response  that  the. 
CODASYL  model  has  received,  including  the  fact  that  it  has  a  decidedly  COBOL 
flavor  to  it.  Finaliy,although  most  of  the  core  concepts  of  the  model  are  defined  and 
agreed  upon,  there  are  many  not-agreed-on  variants  of  the  core  concepts.  These 
variants  create  confusion  and  lead  to  a  dilemma.  [Ref.  7:  p.197] 
e.  DBMS-specific  models 

There  are  over  one  hundred  different  commercial  DBMS  products.  The 
DBMS  are  sometimes  categorized  in  terms  of  their  underlying  data  model.  A  DBMS  is 
considered  a  relational  system  if  it  conforms,  in  essence,  to  the  relational  data  model. 
Alternately,  a  DBMS  is  considered  to  be  a  CODASYL  system  if  it  conforms,  in 
essence,  to  the  CODASYL  DBTG  data  model.  A  third  category  of  DBMS  is  other.  If 
a  DBMS  does  not  conform  to  one  of  the  above  two  data  models,  then  it  has  its  own, 
unique  data  model  There  are  many  systems  that  fall  into  the  other  category. 
[Ref.  7:  p.  158] 

fi  ANSI/ X3 1  SPARC  data  model 

The  ANSI/X3/SPARC(American  National  Standards  Institute  /  Committee 
X3  /  Standards  Planning  and  Requirements  (sub)-Committee)  data  model  does  support 
a  variety  of  different  data  models  in  Figure  2.6.  This  model  is  a  model  for  DBMS 
design  rather  than  for  database  design.  This  have  the  external,  conceptual,  and 
internal  schema.  [Ref.  7:  p.  198] 
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m.  RELATIONAL  MODEL 


A  INTRODUCTION 

A  relation  is  a  mathematical  term  for  a  two-dimensional  table.  It  is  characterised 
by  rows  and  columns,  each  entry  there  being  a  data  item  value.  The  reason  for  calling 
this  a  relation  rather  than  a  matrix  lies  in  the  lack  of  homogeneity  in  its  entries  -  the 
entries  are  homogeneous  in  the  columns  but  not  in  the  rows.  A  relational  data  base 
consists  of  such,  relations,  which  can  be  stored  on  a  physical  device  in  a  variety  of 
ways. 

From  the  late  1960s  a  number  of  people  toyed  with  the  idea  of  constructing  data 
base  with  relations  as  the  basic  building  blocks.  Most  of  these  early  systems  were 
restricted  to  relations  with  only  two  columns,  and  all  of  them  were  special-purpose 
models'  incapable  of  meeting  general  data-processing  requirements*.  In  1970  E.F.  Codd 
of  IBM  proposed  a  model  for  a  generalised  relational  Data  Base  System  chiefly  to 
provide  data  independence  and  data  consistency,  which  are  difficult  to  achieve  in  the 
formatted  Data  Base  Systems.  The  model  was  subsequently  improved  and  expanded 
by  Codd  and  is  now  regarded  by  many  as  the  future  of  all  Data  Base  Systems. 
Needless  to  say,  the  term  relational  data  base  or  relational  model  is  nowadays  generally 
indentified  with  Codd's  model  alone. 

A  basic  feature  of  the  relational  model  is  its  simplicity.  A  relation  is  a  table  of 
data  and  it  may  consist  of  only  one  row  and  one  column,  thus  providing  the  simplest 
possible  data  structure  which  can  be  used  as  the  common  denominator  of  all  data 
structures.  It  simplifies  the  design  of  the  schema  since  there  is  only  one  logical  data 
structure-the  relation-to  consider,  without  having  to  worry  about  the  construction  of 
the  right  data  structures  to  represent  complex  data  relationships.  Furthermore  the 
relational  model  provides  an  unparalleled  freedom  to  the  application  programer  by 
enabling  him  to  access  any  data  item  value  in  the  data  base  directly,  the  access 
mechanism  being  associative  or  content  addressable  since  a  data  item  is  accessed 
directly  by  its  value  rather  than  by  its  relative  position  or  by  a  pointer. 

The  concepts  of  the  relational  model  are  founded  on  mathematics,  and  all  the 
terms  used  are  mathematical.  This  has  the  effect  of  scaring  off  most  people  who  would 
normally  be  interested  in  a  data  base. 
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It  this  chapter  we  dull  keep  the  involvement  with  mathematics  to  a  minimum. 
Al  concepts  wiU  be  defined  in  non-mathematical  terms  in  a  simplified  manner, 
sacrificing  m  the  process  some  of  the  mathematical  rigour  which  is  really  unnecessary 
for  the  understanding  of  the  model,  we  shall  also  give  the  data-processing  equivalent 
of  the  commonly  used  relational  concepts. 

&  BASIC  CONCEPT 
1.  Terminology 

A  relation  is  simply  a  two-dimensional  table  that  has  several  properties.  First, 

the  entries  in  the  table  are  single-valued;  neither  repeating  groups  nor  arrays  are 

allowed.  Second,  the  entries  in  any  column  are  all  of  the  same  kind.  For  example,  one 

column  may  contain  person  numbers,  and  another  ages.  Further,  each  column  has  a 

unique  name  and  the  other  of  the  columns  is  immaterial.  Columns  of  a  relation  are 

referred  to  as  attributes.  Finally,  no  two  rows  in  the  table  are  identical  and  the  order 

*  .  • 

of  the  rows  is  insignificant.  Figure  3.1  portrays  a  relation. 


Kama 

MSN 

Rank 

Age 

Jae  B.  Park 

667423 

Capt 

30 

Sam  N.  Kim 

631242 

Maj 

33 

Young  S.  Jung 

652310 

Maj 

34 

Tae  H.  Choi 

632258 

Col 

44 

Figure  3.1  Korean  Military  Person  Relation. 

Each  row  of  the  relation  is  known  as  a  tuple.  If  the  relation  has  n  columns  or 
n  attributes  is  said  to  be  of  degree  n.  The  relation  in  Figure  3.1  is  of  degree  4,  and 
each  row  is  a  4-tuple. 

Each  attribute  has  a  domain,  which  is  the  set  of  values  that  the  attribute  can 
have.  For  example,  the  domain  of  the  Rank  attribute  in  Figure  3. 1  is  the  three  values, 
Capt,  Maj  and  Col.  The  domain  of  the  Age  attribute  is  all  positive  integers  less 

.  then,say,100. 
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A  relation  of  degree  n  has  n  domains,  not  ail  of  which  need  be  unique.  For 
example,  the  relation  in  Figure  3.2  has  age  and  age  of  spouse  attributes.  The  domains 
of  the  two  attributes  are  the  same,  integers  from  1  to  .100.  To  differentiate  between 
attributes  that  have  the  same  domain,  each  is  given  a  unique  attribute  name.  The 
attribute  names  for  the  relation  in  Figure  3.2  are  Name,  Position,  Spouse-name,  Age, 
Spouse-age,  and  Unit 


Name 

Position 

S_name 

Age 

S_age 

Unit 

Jae  B.  Park 

A 

Eun  K.  LEE 

30 

25 

212SQ 

Sam  N.  Kim 

B 

ki  0.  Sin 

33 

28 

117SQ 

You  S.  Jung 

C 

Hye  S.  Lee 

34 

29 

808SQ 

Tae  H.  Choi 

D 

Myen  J.  Cho 

44 

42 

512SQ 

'  Figure  3.2  Korean  Air  Force  Pilot  Relation. 

Figures  3.1  and  3.2  are  examples,  or  occurences.  The  generalized  format, 
KOREAN  MILITARY  PERSON  (Name,  MSN,  Rank,  Age),  is  called  the  relation 
structure,  and  is  what  most  people  mean  when  they  use  the  term  relation.  If  we  add 
constraints  on  allowable  data  values  to  the  relation  structure,  we  then  have  a  relational 
schema.  [Ref.  7:  pp243,245] 

As  mentioned  earlier,  a  relation  is  a  mathematical  term  used  to  define  a 
special  kind  of  table.  Each  column  is  called  a  domain  containing  all  the  values  of  an 
attribute,  and  each  row  a  tuple.  The  word  tuple  is  taken  from  the  description  of 
groups,  such  as  quintuple  and  sextuple.  Thus  a  group  of  n  elements  is  an  n-tuple.  In 
a  relation  of  n  domains,  each  tuple,  that  is,  each  row,  is  an  n-tuple.  The  number  of 
rows  or  tuples  in  a  relation  is  its  cardinality,  and  the  number  of  columns  is  its  degree. 
The  individual  elements  in  a  relation  are  attributes  values.  If  we  consider  an  m  *  n 
relation  (  m  rows  and  n  columns ),  we  have. 

a  relation  of  degree  n  and  cardinality  m,  that  is, 
a  relation  containing  n  domains  and  n  tuples,  each 
tuple  being  an  n-tuple..  There  are  m  *  n  attribute 


31 


nluM,  u*ch  topi*  having  n  coluans  nr  n  attributa 
vaiuaa. 

A  relation  of  degree  1  If  called  unary,  degree  2  binary,  degree  3  ternary  and 
degree  n  nary  relation.  The  characteristics  of  a  relation  are  as  follows. 

(1)  All  entries  in  a  domain  are  of  the  same  kind. 

(2)  Domains  are  assigned  distinct  names  called  attribute- names. 

(3)  The  ordering  of  the  domains  is  immaterial 

(4)  Each  tuple  is  distinct,  that  is,  duplicate  tuples  are  not  allowed. 

(5)  The  ordering  of  the  tuples  is  immaterial  [Ref.  8:  p.  1 32] 

2.  Attribute  and  domain  names 

A  domain  .unlike  a  tuple,  can  be  duplicate.  A  domain  name  is  the  common 
name  for  identical  domains  whereas  an  attribute  name  is  the  unique  name  for  an 
individual  domain.  Attribute  names  for  identical  domains  are  constructed  from  the 
common  domain  name  by  attaching  suitable  prefixes  to  it  Consider,  for  instance,  a 
relation  called  HIERARCHY  containing  two  identical  domains  -  one  for  the  superior 
unit  number  and  the  other  for  subordinate  unit  number  -  both  holding  the  same  type 
of  information,  that  is,,  unit  number  codes.  If  we  assume  a  common  domain  name, 
UNIT,  then  we  can  construct  two  attribute  names,  SUP-UNIT  for  the  superior  unit 
numbers,  and  SUB-UNIT  for  the  subordinate  unit  numbers.  Unit  code,  for  instance,  is 
DIV  for  division,  IRE  for  infantry  regiment,  ARE  for  artillery  regiment,  IBA  for 
infantry  battalion,  ABA  for  artillery  battalion  etc.  Using  QUANTITY  as  the  attribute 
name  for  the  third  domain  which  contains  the  numbers  of  a  subordinate  unit  numbers 
present  in  its  superior  unit  number,  we  can  represent  the  triplet  as  shown  in  Figure  3.3. 

From  the  mathematical  point  of  view,  a  domain  can  be  simple  or  non  simple, 
a  simple  domain  containing  a  single  attribute  and  a  nonsimple  domain  containing  a 
repeating  group  or  a  multiple  of  attributes.  Therefore  the  name  of  a  simple  domain 
can  be  identical  with  that  of  its  attribute.  A  nonsimple  domain  can  be  broken  down 
into  simple  domains,  giving  each  a  unique  attribute  name  as  we  have  done  in  the 
example  above. 

3.  Keys  and  attributes 

A  tuple  is  identified  by  its  key,  constructed  from  a  combination  of  one  or 
more  attributes  so  that  no  attribute  there  is  redundant.  A  tuple  can  have  more  than 
one  possible  key,  each  of  which  can  uniquely  identify  the  tuple.  All  these  possible  keys 
are  known  as  the  candidate  keys.  One  of  these  keys  is  arbitrarily  selected  to  identify 
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tttRAXCKY  (  fOF.WTIT 

SUB_UNIT 

QUANTITY  ) 

DXV  102 

IRE  572 

6 

DIY  104 

ARE  337 

3 

ARE  337 

ABA  325 

5 

IRE  572 

IBA  153 

5 

Figure  3.3  A  Relation  of  Degree  3. 

the  tuple  and  this  key  is  known  as  the  primary  key.  For  example,  consider  a  tuple  with 
the  following  attributes 

Division  Cods,  Rsginsnt  Cods,  Regiment  Commander  No., 

No.  of  people. 

If  we  assume  that  every  regiment  has  its  own'  separate  commander,  then  this 
tuple  can  be  uniquely  identified  either  by  Division  Code  +  Regiment  Code  ,  or 
Division  Code  +■  Regiment  Commander  No:  These  then  are  two  candidate  keys,  one 
of  which  can  be  selected  as  the  primary  key.  Since  a  key  must  not  contain  redundant 
attributes,  the  Regiment  Code  and  Regiment  Commander  No.  can  not  appear  in  the 
same  key,  because  the  Regiment  Commander  No.  implicitly  defines  Regiment  Code. 

If  a  tuple  has  attributes  whose  combination  is  the  primary  key  in  another 
relation,  then  this  combination  is  called  a  foreign  key.  For  instance  Division  Code  can 
be  a  foreign  key.  An  attribute  that  forms  a  part  of  a  candidate  key  is  a  prime 
attribute  of  the  tuple.  The  other  attributes  are  nonprime.  In  the  example  given  above, 
the  Division  Code,  Regiment  Code  and  Regiment  Commander  No.  are  prime 
attributes,  and  the  No.  of  people  is  a  nonprime  attribute. 

4.  Comparison  with  standard  data-processing  concepts 

In  data-processing  terms  we  may  approximate  a  relation  to  the  occurrences  of 
a  record  type,  a  tuple  to  a  record  occurrence,  and  an  attribute  to  a  data  item,  a  domain 
being  the  collection  of  all  values  for  a  single  data  item.  Degree  is  the  number  of  data 
items  in  the  record  and  cardinality  is  the  total  number  of  records  in  the  record  type.  A 
unary  record  relation  is  a  record  type  consisting  of  a  single  data  item;  a  binary  relation 
is  a  record  type  of  two  data  items;  and  so  on. 
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However,  there  are  some  differences  between  record  types  and  relations  in 
third  normal  form,  a  record  type  being  equivalent  to  an  unnormalised  relation  where 
repeating  groups  are  permitted.  Normalised  form  will  be  discussed  in  Chapter  IV.  The 
ordering  of  the  data  items-that  is,  their  relative  positions-is  fixed  in  a  record  type  and 
cannot  be  altered,  but  the  domains  of  a  relations  are  independent  of  their  relative 
positions  since  they  are  addressed  individually  by  their  attribute  names.  In  a  relation, 
the  ordering  of  tuples  is  also  unimportant  because  each  of  them  is  accessed  directly, 
but  this  is  not  generally  true  for  the  records  of  a  record  type,  unless  they  are 
specifically  stored  for  direct  retrieval.  These  access  advantages  follow  directly  from  the 
content-addressable  accessing  concept  used  in  relations  as  mentioned  earlier.  Finally 
by  definition  a  relation  can  have  a  duplicate  tuple,  but  there  is  no  such  conceptual 
restriction  on  the  existence  of  a  duplicate  record  in  a  record  type.  These  discussions 
are  summerized  in  Figures  3.4  and  3.5.  [Ref.  8:  p.  134] 


Relational  Tarns 

Data-processing  Tarns 

Halation 

All  tha  occuranca  of  a  records  typo 

Tuple 

Record 

Attribute 

Data  item 

• 

Domain 

All  tha  values  of  a  data  item 

Degree 

Number  of  data  itans  in  the 

record  type 

Cardinality 

Total  number  of  records  in  the 

record  type 

Figure  3.4  Equivalence  of  relational  terms  with  data-processing  concepts5. 


'Deen  S.  M.,  Fundamentals  of  Database  Systems,  p.  134,1  layden  book  company 
INC., Rochelle  park,  New  Jersy  1973 


Item 

Halation 

Record  type 

Repeating  group 

Not  allowed  in 

normalised  ralations 

Allowed 

Odering  of 

domains  or  data 

itama 

Immaterial 

Important 

Ordaring  of 

tuplas  or  racords 

Immaterial 

Important 

Duplicate  tupla  . 

Not  Allowed. 

Immaterial 

or  racord 

Figure  3.5  Difference  between  relation  and  data-processing  concepts6. 

C.  EXPRESSING  RELATIONSHIPS  WITH  THE  RELATIONAL  MODEL 

When  we  design  a  database,  we  may  need  to  specify  the  logical  relationships  that 
will  exist  among  data  base  records.  When  we  consider  the  user's  requirement,  we 
should  realize  that  there  are  three  fundamental  types  of  record  relationships.  These 
types  are:  tree(  or  hierarchy  ),  simple  network,  and  complex  network. 

Many  relations  which  are  based  on  those  three  types  of  record  relationships  will 
be  discussed  in  this  section.  First  of  all,  each  type  of  relationship  is: 

(1)  Tree?  or  hierarchies.  A  tree  is  a  collection  of  records  and  one-to-many 
relationships  among  records.  According  to  standard  terminology,  the  records 
are  called  nodes,  and  the  relationship  between  the  records  are  called  branches. 
The  node  at  the  top  of  the  tree  is  called  the  root.  Eyery  node  ol  a  tree  has  a 
parent-the  node  immediately  above  it.  Figure  3.6  shows  a  tree  relationship. 

(2)  Simple  Networks.  A  simple  network  is  also  a  collection  of  records  and  one- 
to-many  relationships  among  records.  In  a  simple  network,  a  record  mav 
have  more. than  one  parent,  as  long  as  the  parents  are  different  types  of 

6Deen  S.  M.,  Fundamentals  of  Database  Systems ,  p.  134, Hayden  book  company 
INC., Rochelle  park,  New  Jersey  1973 
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Figure  3.6  Example  of  Tree  Relationship. 

records.  Figure  3.7  shows  a  simple  network  relationship. 

4 

(3)  Complex  Networks.  A  complex  network  is  also  a  collection  of  records  and 

relationships.  The  relationships  are  manv-to-manv  instead  ol  one-to-many. 

Figure  3.8  shows  Complex  Network  Relationship. 

1.  Tree  or  hierarchical  relationships 

The  tree  which  is  illustrated  in  Figure  3.6  can  be  modeled  by  constructing  two 
relations  as  in  Figure  3.9. 

Relation  ML  contains  the  Name,  Mission,  Location  attributes,  and  relation 
PILOT  contains  the  Name  and  Pilot  attributes.  Name  is  primary  key  of  the  ML 
relation,  and  Name  and  Pilot  together  are  the  primary  key  of  the  PILOT  relation.  This 
relational  representation  is  useful  when  we  need  a  information  about  pilots  who  work 
in  specific  wing  or  squadron. 

2.  Simple  Network  Relationships 

Consider  the  undergraduate  education/squadron/pilots  relationship  as  it  is 
shown  in  Figure  3.7.  As  we  mentioned  earlier,  Figure  3.7  represents  a  simple  network 
relationship.  In  Figure  3.10,  the  following  relation  structure  will  represent  this 
network: 


EDUCATION  (  School,  Major,  GradLyear  ) 


Rim  Mission  Location 


1st  AFB 

TFW 

Seoul 

2nd  AFB 

RFW 

Pussn 

3rd  AFB 

ATW 

Taegu 

*  AFB:  Air  Fores  Bass 

*  TFW:  Tactical  Fightsr  Wing 

*  RFW: Rescue  Flying  Wing  ' 

*  ATW:Air  Trasfortation  Wing 


Kama 

Pilot 

1st  AFB 

Jae.  B.  Park 

1st  AFB 

Jung  S.  Kim 

1st  AFB 

Dong  I.  Oh 

2nd  AFB 

Kil  D.  Hong 

2nd  AFB 

Jung  G.  Lee 

3rd  AFB 

Tae  S.  Jeong 

3rd  AFB 

Kyo  M.  Kang 

a.  Mission  and  Location 
(ML)  relation 


b.  PILOT  relation 


Figure  3.9  Relational  Representation  of  Tree  Relationship. 

PILOT  (Mil_serv_num/  Mams,  School,  Major,  Squadron  ) 

As  it  is  shown  in  Figure  3.10,  there  are  no  special  constructs  to  represent  the 
relationship. 

Instead,  relationships  can  be  determined  by  pairing  equal  values  of  attributes. 
These  relations  are  very  useful  when  we  need  some  information  about  pilots  who 
graduate  from  a  specific  school  and  study  specific  subjects.  For  example,  let's  assume 
that  we  want  to  know  how  many  pilots  work  with  Jae  B.  Park.  To  respond  to  this 
query,  we  can  find  PILOT  tuples  for  Jae  B.  Park.  Next,  we  can  find  the  number  of 
pilots  from  333rd  SQ  tuple  in  the  SQUADRON  relation. 

3.  Complex  Network  Relationships 

The  relational  model  representation  of  a  comp-ex  relationship  is  similar  to 
that  of  simple  network  relationship.  Figure  3.11  is  based  on  Figure  3.8.  A 
straightfoward  way  of  representing  this  structure  is  to  define  three  relations:  one  lor 

/  • 
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EDUCATION  Relation 


School 
AF  Academy 
2nd  AF  Academy 
Air  College 


Major 

Mechanical  Eng. 

O.R _ 

Management 


G_year 

1980 

1977 

1982 


SQUADRON  Relation 


Name 
333rd  SQ 
505th  SQ 


N_pilot 

10 

50 


MSN  Name 


PILOT  Relation 
School 


Major 


61543  Jar  Park 

AF  Academy 

65320  Gil  Hong 

2nd  AF 

Academy 

54252  Tae  Lee 

Air  College 

Squadron 


333rd  SQ 


505th  SQ 


270th  SQ 


Figure  3.10  Relational  representation  of  Simple  Network  Relationships. 


pilots,  one  for  military  training  courses,  and  one  for  the  relationship  between  pilots  and 
military  training  courses.  This  last  relation  is  an  intersection  record.  The  following 
relation  structure  will  represent  this  network: 

PILOTS  (  Mil_serv_num,  Name,  Rank  ) 


lire  {  Cour_name,  Year,  Nun-student  ) 

PILOT_MTC  (  Mil._serv.juim,  Cour_narae  ). 

It  is  very  easy  to  find  someone's  career  by  using  these  relations.  For  example, 
let's  consider  the  question  "What  kinds  of  military  training  courses  has  Capt.  Jae  Park 
taken  so  far?’.  According  to  Figure  3.11,  he  took  AGOC  and  CADT  course. 


Name 


Rank 


61543 

Jae  Park 

Capt 

65320 

Gil  Hong 

Capt 

54252 

Tae  Lee 

Col 

Cname 

Year 

No.Student 

AGOC 

83-7 

50 

ABC 

82-5 

60 

CADT 

83-8 

70 

ISP 

84-3 

80 

PILOTS  Relation 


MTC( military  training 
course)  Relation 


MSN 

61543 

61543 

65320 

65320 

54252 

54252 


Cname 

AGOC 

CADT 

CADT 

ISP 

ABC 

ISP 


PILOTS_MTC  Relation 


Figure  3.11  Relational  representation  of  Complex  Network  Relationship. 
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To  nwnifxikte  dtfa  in  the  database  by  the  appteation  program  we  used  a 
Dili  M>njpol»rir>n  Language  or  PML»  oot  for  —eh  hot  tenant.  The  DML  acts  if 
in  tomiheo  tomm  with  the  databa at.  Its  major  fractions  are 
io  sewa  i  racora  irwn  d  wtiwi 
to  reprucm  n  to  um  ippuciuon  pro|rain 

•  to  add  new  records  and  relationships  in  the  database 

•  to  change  existing  records  and  relationships  in  the  database 

•  to  remove  existing  records  and  relationships  from  the  database 
[Ref.  8:  p.52]. 

As  it  is  discussed  in  Figure  3.11,  understanding  of  representations  of  three 
relationships  are  very  important  to  get  flexible  and  useful  information  in  a  personnel 
management  system.  Each  relationship  is  useful  for  individual  required  characteristic 
of  query.  An  example  is  shown  in  Figure  3.11. 


D.  DATA  MANIPULATION  LANGUAGES 


The  notation  for  expressing  queries  is  usually  the  most  significant  part  of  a  data 
manipulation  language.  The  nonquery  aspects  of  a  relational  data  manipulation 
language,  or  'query  language,"  are  often  straightfoward,  being  concerned  with  the 
insertion,  deletion  and  modification  of  the  tuples.  On  the  other  hand,  queries,  which  in 
the  most  general  case  are  arbitrary  functions  applied  to  relations,  often  use  a  rich,  high 
level  language  for  their  expression. 

Query  languages  for  the  relational  model  break  down  into  two  broad  classes: 

(1)  Algebraic  languages,  where  queries  are  expressed  by  applying  specialized 
operators  to  relations,  and 


(2)  Predicate  calculus  languages,  where  queries  describe  a  desin 
specifying  a  predicate  the  tuples  must  satisfy.  [Ref.  6:  p.104] 


ed  set  of  tuples  by 


1.  Relational  algebra 

Relational  algebra  operates  one  or  more  relations  and  produces  a  new  relation 
as  the  result.  The  operations  are  expressed  in  a  system  of  notation  and  they  can  be 
used  to  retrieve  information  from  one  or  more  relations  or  to  update  a  tuple  of  a 
relation.  We  shall  describe  here  six  operations  of  which  the  first  three-  union, 
intersection  and  difference  are  traditional  set  operations;  the  other  three  -  projection, 
join  and  division  •  are  less  common.  Relations  can  be  manipulated  using  the 
opertators  +  ,  etc.,  in  high  school  algebra  to  achieve  a  desired  result.  Relation 
algebra  is  hard  to  use,  partly  because  it  is  procedural.  That  is,  when  using  relational 
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algebra  w»  met  know  not  onfy  what  we  want,  but  also  how  to  get  it  In  high  school 
algebra,  mitblas  represented  numbers,  and  operations  Hke  +,  * ,  and/  operated  on 

numeric  quantities.  For  relational  algebra,  however,  the  variables  are  relations,  and  the 
operations  manipulate  relations  to  form  new  relations.  For  example,  the  operation  +  ( 
or  union  )  combines  the  tuples  of  one  relation  with  the  tuples  of  another  relation. 
(Rif.  7:  p.255] 

«.  Unm i 

The  union  of  set  A  with  set  B,  denoted  as  A  U  B,  is  the  set  of  all  objects 
without  repetition.  We  only  apply  the  union  operator  to  relations  of  the  same  number 
of  attribute,  so  all  tuples  in  the  result  have  the  same  number  of  attribute.  Each 
attribute  should  have  same  domain.  This  can  be  used  to  insert  a  new  tuple  to  a 
relation. 

b.  Intersection 

The  intersection  of  set  a  with  set  B,  denoted  as  A  fl  B,  is  the  set  of  all 
objects  belonging  to  both  A  and.  B.  So  the  intersection  of  two  relations  is  a  third 
relation  containing  common  tuples.  Again,  the  relations  must  be  union  compatible. 
This  can  be  used  to  find  a  duplicate  tuple  between  two  relations. 

c.  Difference 

The  difference  of  set  b  from  set  a,  denoted  as  A  -  B,  is  the  set  of  all  objects 
belonging  to  A  but  not  to  B.  That  is,  the  difference  of  two  relations  is  a  third  relation 
containing  tuples  which  occur  in  the  first  relation  but  not  in  the  second.  The  relations 
must  be  union  compatible.  This  can  be  applied  to  delete  a  tuple.  To  amend  a  tuple, 
we  must  first  delete  it  with  a  difference  operation  and  then  insert  the  amended  tuple  by 
a  union  operation. 

d.  Projection 

Projection  is  the  selection  of  one  or  more  named  domains  from  a  relation  in 
a  specified  order,  followed  by  the  elimination  of  duplicate  tuples  from  the  resulting 
relation.  (  In  fact  in  all  operations  used  in  relational  algebra,  duplicate  tuples  are 
removed  since  they  are  not  allowed  in  a  relation.)  That  is,  the  result  of  the  projection 
is  a  new  relation  having  the  selected  attributes.  In  other  words,  projection  picks 
columns  out  of  a  relation.  Since  the  result  of  projection  is  a  relation,  and  since 
relations  can  not  contain  duplicate  tuples,  the  redundant  tuple  is  eliminated. 
Projection  can  also  be  used  to  change  the  order  of  attributes  in  a  relation.  We  shall 
use  the  notation  R  [  ABC  ]  to  denote  the  projection  of  domains  A,  B  and  C  in  that 
order  from  relation  R. 
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The  join  operation  is  a  combination  of  the  product,  and  projection 
operations.  The  join  of  relation  A  with  relation  B  produces  a  relation  R  that  consists 
of  all  the  possible  tuples  obtained  by  concatenating  each  tuple  of  A  with  all  tuples  of  B 
that  have  the  same  value  under  the  common  domain.  A  tuple  of  an  original  relation  is 
excluded  from  the  resultant  relation  if  its  value  under  the  common  domain  is  not 
shared  by  a  tuple  of  the  other  relation.  The  resultant  relation  contains  all  the  domains 
of  both  the  original  relations,  the  common  domain  appearing  only  once.  Let's  assume 
there  are  two  relations  A  (  SQUADRON  PILOT  )  and  B  (  PILOT  MTC  )  as  given 
below. 

A( SQUADRON  PILOT)  B( PILOT  MTC) 


255SQ 

Jae 

B.  Park 

Jae  B.  Park 

AGOC 

303SQ 

Dong 

I.  Lee 

Jae  B.  Park 

CADT 

506SQ 

Jang  K.  Cho 

Jang  K.  Che 

ISP 

355SQ 

Jae 

S.  Jeong 

Hwan  S.  Lee 

ABC 

Their  join 

R  is 

R  ( 

SQUADRON 

PILOT 

MTC  ) 

255SQ 

Jae  B.  Park 

AGOC 

255SQ 

Jae  B.  Park 

CADT 

506SQ 

Jang  K.  Cho 

ISP 

For  operational  convenience,  in  all  subsequent  join  operations,  we  shall 
assume  the  common  domain  to  be  the  rightmost  domain  of  the  first  relation  and  the 
leftmost  domain  of  the  second  relation  as  it  is  shown  above;  this  can  be  ensured  if 


necessary  by  a  suitable  projection  operation.  Join  in  conjunction  with  the  projection 
operation  provides  a  very  useful  tool  for  the  manipulation  of  relations. 
f  Product 

The  product  of  two  relations  {  cartesian  product  )  is  the  concatenation  of 
every  tuple  of  one  relation  with  every  tuple  of  a  second  relation.  The  product  of 
relation  A  (  having  m  tuples )  and  relation  B  (  having  n  tuples  )  has  m  times  n  tuples. 
The  product  is  denoted  A  x  B  or  A  times  B.  [Ref.  7:  p.257] 
g.  Division 

We  may  divide  a  binary  relation  by  a  unary  relation  if  the  domain  of  the 
unary  relation  is  also  a  domain  of  the  binary  relation.  The  result  of  such  a  division  is  a 
unary  relation  containing  the  uncommon  domain  of  the  binary  relation  is  selected  for 


the  resultant  relation,  if  its  associated  entries  in  the  common  domain  contain  all  the 
values  of  the  divisor  domain.  Consider  a  binary  relation  DT  and  three  unary  relations 
Dl,  DJ  nid  DK  as  given  below. 

OT  (  S#  P#  )  DI  (P#)  DJ  (P#)  DK  (P#) 

SI  PI  PI  PI  PI 

SI  ?2  P2  P2 

SI  P3  P3 

51  P4 

52  PI 
S2  P3 

52  P4 

53  PI 
S3  P2 

Denoting  division  by/(  slash)  and  the  resultant  relation  by  R,  we  have 


DT/DI=R(S#) 

DT/DJ*R(  S#) 

DT/DK=R( S#) 

SI 

SI 

SI 

S2 

S3 

S3 

For  operational  convenience  in  division,  as  in  join,  we  shall  assume  the 
rightmost  (that  is,  the  second)  domain  of  the  dividend  as  the  common  domain.  All 
algebraic  operations  will  be  evaluated  from  right  to  left  giving  precedent  to  projection 
operation  over  join  and  division,  the  priority  over  projection  being  indicated  by 
ordinary  brackets( ). 

Relational  algebra  can  be  used  for  a  procedural  language.  It  is  extremely 
powerful  and  is  device  independent,  since  the  queries  are  based  on  the  values  of  the 
data  items  rather  than  their  positions.  However,  the  construction  of  an  algebraic 
expression  for  a  query  is  very  tedious,  even  though  the  technique  can  quickly  be  learnt. 
In  addition,  the  nature  of  a  query  is  not  obvious  from  the  algebraic  expression  unless  it 

i 

is  patiently  worked  out.  These  tend  to  increase  the  chances  of  errors  in  the  queries. 
Relational  calculus  is  designed  to  improve  this  situation.  [Ref.  8:  p.  1 50] 

2.  Relational  calculus 

Relational  calculus  is  one  of  the  strategies  for  manipulating  relations.  It  is  a 
nonprocedural  language  for  expressing  what  we  want  without  expressing  how  to  get  it. 
In  relational  algebra  the  user  specifies  the  detailed  procedures  for  extracting 


information,  whereas  in  relational  calculus  the  user  defines  what  he  wants,  leaving  the 
system  to  work  out  the  procedure  required.  The  expression  of  a  relational  calculus  has 
two  parts,  a  target  list  which  consists  of  a  fist  of  the  wanted  elements  separated  by 
commas,  and  a  logical  expression,  called  a  predicate  or  qualification,  which  defines  the 
wanted  dements  in  terms  of  the  relations  from  which  they  are  to  be  extracted.  It  is 
written  in  the  form 

Target  list  :  predicate 

to  be  interpreted  as:  extract  the  elements  in  the  target  list  such  that  (  or  where)  the 
predicate  is  true.  [Ref.  8:  p.  152] 
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IV.  RELATIONAL  DATABASE  DESIGN 


A.  INTRODUCTION 

The  combination  of  DBMS  software,  applications  software,  database 
implementation,  and  operating  system/hardware  environment  brought  together  to 
provide  information  services  for  users  is  known  as  a  database  system.  Although  the 
technology  for  DBMS,  operating  system,  and  applications  programming  is  well 
developed,  little  attention  has  been  given,  to  the  effective  use  of  these  tolls  with 
alternative  database  structures.  Thus,  the  major  problem  facing  the  database 
administrator  is  not  whether  to  use  this  technology,  but  how  to  use  it  effectively.  This 
problem  can  be  summarized  by  a  number  of  issues  that  arise  through  the  life  cycle  of 
an  application: 

(1)  What  are  the  user  requirements,  and  how  can  they  be  expressed? 

(2)  How  can  these  requirements  be  translated  into  an  effective  database  structure? 

(3)  When,  should,. and  how  can,  the  database  structure  be  adapted  to  new  and/or 
changing  requirements? 

The  process  of  developing  a  database  structure  from  user  requirements  is  called 
database  design.  Many  practitioners  have  argued  that  they  are  at  least  two  separate 
steps  in  the  database  design  process:  the  design  of  a  logical  database  structure  which  is 
processible  by  the  DBMS  and  describes  the  user's  view  of  the  data,  and  then  selection 
of  a  physical  structure  that  includes  data  representation  or  encoding,  access  methods, 
and  physical  clustering  of  data.  Other  than  the  logical/physical  delineation,  however, 
the  overall  structure  of  the  design  process  has  not  been  well  defined,  and  even  the 
logical/ physical  boundary  has  been  open  to  considerable  dispute.  We  wish  to  avoid 
this  confUsion  by  defining  more  concisely  each  step  in  the  design  process. 

Database  design  is  an  intuitive  and  artistic  process.  There  is  no  algorithm  for  it. 
Typically,  database  design  is  an  iterative  process;  during  each  iteration,  the  goal  is  to 
get  closer  to  an  acceptable  design.  Thus  a  design  will  be  developed  and  then  reviewed. 
Defects  in  the  design  will  be  identified,  and  the  design  will  be  redone.  This  process  is 
repeated  until  the  development  team  and  users  can  find  no  major  defects.  ( 
Unfortunately,  this  does  not  mean  the  design  will  work;  it  simply  means  no  one  can 
think  of  any  reason  why  it  won't.) 
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The  database  it  the  bridge  between  people  and  hardware.  As  mentioned  earlier, 
the  characteristics  of  both  people  and  hardware  need  to  be  considered.  Consequently, 
database  design  is  divided  into  two  phases:  logical  design,  where  the  needs  of  people 
are  specified,  and  physical  design,  where  the  logical  design  is  mapped  into  the 
constraints  of  particular  program  and  hardware  products.  Figure  -4.1  illustrates  the 
flow  of  work  in  a  typical  database  design  project.  User  requirements  are  studied  and  a 
logical  database  design  is  developed.  Concurrently,  the  preliminary  design  of  database 
processing  programs  is  produced.  Next,  the  logical  database  and  the  preliminary 
program  designs  are  used  to  develop  the  physical  database  design  and  the  detailed 
program  specifications.  Finally,  both  of  these  are  input  to  the  implementation  phase 
of  the  project. 

This  chapter  will  introduce  theoretical  logical,  physical  database.  And  then  we 
will  discuss  about  relation  database  design  in  detail  and  hypothetical  Korean  Army  or 
Air  Force's  data  will  be  used  to  show  examples. 

Practical  sample  application  program  is  shown  in  Appendix  A. 
[Ref.  7:  pp.  177, 178] 


Figure  4.1  Database  and  Program  Design  Flow7. 


Science^llesearch^Asso  ^te  ^U^Cai9 processing :  Fundamentals,  Design,  Implementation, 
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B.  LOGICAL  DATABASE  DESIGN 

Conceptual  design  deals  with  information  independent  of  any  actual 
implementation.  It  is  the  objective  of  conceptual  design  to  represent  information  in  a 
form  that  is  comprehensible  to  the  user  independent  of  system  specifies,  but 
implemen table  on  several  systems. 

1.  Outputs  of  logical  database  design 

A  logical  database  design  specifies  the  logical  format  of  the  database.  The 
records  to  be  maintained,  their  contents,  and  relationships  among  those  records  are 
specified.  Industry  uses  various  terms  for  this  design.  It  is  sometimes  called  the 
schema,  the  conceptual  schema,  or  the  logical  schema.  We  will  use  the  term  logical 
schema  because  it  is  the  schema  developed  during  logical  design. 

a.  Logical  database  records 

To  specify  logical  records,  the  designer  must  determine  the  level  of  detail  of 
the  database  model  If  the  model  is  highly  aggregated  and  generalized,  there  will  be 
few  records.  If  model  is  detailed,  there  will  be  many  records.  The  database  designer 
must  examine  the  requirements  to  determine  how  coarse  or  how  fine  the  database 
model  should  be.  The  content?  of  these  records  are  specified  during  logical  design. 
Figure  4.2  shows  an  example  of  field  description. 

b.  Logical  database  record  relationship 

The  essence  of  database  is  the  representation  of  record  relationships.  These 
relationships  are  specified  during  logical  design.  The  designer  studies  the  application 
environment,  examines  the  requirements,  and  identifies  necessary  relationships. 

Figure  4.3  shows  possible  relationships  for  several  records  in  military 
personnel  management  system's  database.  The  arrows  represent  many-to-many 
relationships  between  database  records.  Data  structure  diagrams  are  not  the  only  tool 
for  expressing  relationships.  To  summarize,  their  content,  constraints,  and 
relationships. 

2.  Inputs  to  logical  database  design 

The  inputs  to  logical  database  design  are  the  system  requirements  and  the 
project  plan.  Requirements  are  determined  by  interviews  with  users,  and  that  they  are 
approved  by  both  users  and  management.  The  project  plan  describes  the  system 
environment,  the  development  plan,  and  constraints  and  limitations  on  the  system 
design. 


Timid 

Description 

PERSON  Record 

Rank 

Alphabetic, 

0 

25  character  • 

Military_Serice_Number 

Numeric ,  15 

decimal  degit 

Nana 

Alphabetic, 

25  characters 

Address 

Alphabetic, 

70  characters 

MILITARY 

CAREER  Record 

Military  Service  Number 

Numeric,  15 

decimal  degit 

Unit__name 

Alphabetic, 

20  characters 

Duty  _name 

Alphabetic ,. 

30  characters 

Duty_rank 

Alphabetic, 

25  characters 

Data 

Format  :  YYMMDD 

Figure  4.2  Sample  field  description  for  PERSON  and  MILITARY  CAREER  records. 

The  requirement  will  be  expressed  in  the  form  of  data  (low  diagrams,  policy 
statements,  and  the  data  dictionary.  Having  the  requirements  in  this  form  will  greatly 
facilitate  the  logical  design  process.  Contents  of  the  data  dictionary  can  be 
transformed  into  the  logical  and  user's  views.  Policy  statements  can  be  used  to  develop 
the  descriptions  of  logical  database  processing.  The  requirements  can  be  used  to  verify 
the  completeness  of  the  logical  design.  If  the  requirements  are  defined  in  narrative 
style,  they  will  need  to  be  converted  to  a  format  that  facilitates  logical  database  design. 

3.  Procedures  for  logical  database  design 

The  major  steps  in  the  logical  design  process  are  described  below. 

(1)  Identify  data  to  be  stored.  The  data  dictionary  is  processed  and  data  that  is 
to  be  stored  is  identified  and  segregated. 
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Figure  4.3  Data  Structure  Diagram. 


(2)  Consolidate  and  clarify  data  names.  One  task  is  to  identify  synonyms,  to 
decide  on  standard  names  for  synonyms,  and  to  record  aliases.  Synonyms  are 
two  or  more  names  for  the  same  data  item. 

(3)  Develop  the  logical  schenja.  The  third  step  in  the  design  process  is  to  develop 
the  logical  schema  by  defining  records  and  relationships.  Records  are  defined 
by  determining  the  data  items  they  will  contain. 

(4)  Define  processing.  The  requirements  are  examined  to  deteirnine  how  the 
database  should  Be  manipulated  to  produce  required  results.  The  processing 
defines  can  be  developed  in  several  ways.  One  method  is  to  describe 

<  transactions  and  data  to  be  modified.  Another  method  for  describing 
database  processing  is  to  develop  structure  charts  of  the  programs  that  win 
access  the  database.  One  method  for  developing  such  processuig  descriptions 
is  called  transform  analysis. 

(5)  Design  review.  The  logical  schen\a  and  user  views  are  examined  in  light  of  the 
requirements  and.  program  descriptions.  Every  attepipt  is  made  to  identify 
omissions,  unworkable  aspects,  or  the  flaws  in  the  design.  [Ref.  7:  p.181] 


C.  PHYSICAL  DATABASE  DESIGN 

The  second  stage  of  database  design  -  physical  design  -  is  a  stage  of 
transformation.  The  logical  schema  is  transformed  into  the  particular  data  constructs 
that  are  available  with  the  DBMS  to  be  used.  Whereas  the  logical  design  is  DBMS  - 
independent,  the  physical  design  is  very  much  DBMS  -  dependent. 

1.  Outputs  of  physical  database  design 

Specific  constructs  vary  widely  from  one  DBMS  to  another.  At  this  point,  we 
can  not  be  very  detailed.  In  general,  two  major  specifications  are  produced.  First,  the 
physical  specification  of  the  logical  schema  is  defined.  We  will  call  this  specification 
the  physical  schema.  This  schema  is  transformation  of  the  logical  schema  into  the  data 
modeling  constructs  available  with  the  DBMS  to  be  used.  Second,  user  views  are 
defined. 
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PHYSICAL  SCHEMA.  The  content  of  each  record  must  be  defined,  and  the 
name  and  format  of  each  field  of  each  record  specified.  Constraints  from  the  logical 
database  design  are  transformed  into  criteria  for  field  descriptions.  Keys  of  database 
records  need  to  be  identified,  and  overhead  structures  for  supporting  the  keys  defined. 
For  example,  the  designer  may  specify  that  a  particular  key  is  to  be  supported  by  an 
inverted  list.  Record  relationships  are  also  defined  in  the  physical  design.  Limitations 
in  the  DBMS  may  necessitate  that  record  relationships  be  changed  from  what  the  users 
wanted.  A  many-to-many  relationship  may  need  to  be  changed  to  a  simple  network, 
for  example. 

USER  VIEWS.  The  second  component  of  a  physical  database  design  is  the 
user  views.  Since  most  users  will  need  to  view  only  a  portion  of  the  database,  the 
logical  design  must  specify  which  user  groups  will  view  which  portions  of  the  database. 

User  views  are  generally  a  subset  of  the  schema.  Records  or  relationships  may 
be  omitted  from  a  view,  fields  may  be  omitted  or  rearranged.  Also,  the  names  of 
records,  fields,  or  relationships  may  be  changed.  This  flexibility  allows  uers  to  employ 
terminology  that  is  familiar  and  useful  to  them.  [Ref.  7:  pp.  188,189] 

2.  Inputs  to  logical  >  atabase 

The  inputs  to  the  physical  database  design  are  the  outputs  of  the  logical 
database  design,  the  system  requirements,  and  the  preliminary  design  of  programs. 

3.  Physical  design  steps 

The  physical  design  phase  can  also  be  categorized  into  distinct  steps  based  on 
groups  of  related  design  decisions.  However,  once  again,  the  proper  ordering  of  these 
steps  is  open  to  conjecture,  owing  to  the  fairly  strong  dependencies  between  these 
groups  of  design  decisions.  Practical  experience  has  shown  that  neither  the  starting 
point  nor  the  order  of  steps  can  be  definitely  stated  for  a  given  design  problem.  On  the 
other  hand,  the  physical  design  phase  can  be  regarded  as  an  iterative  process  of  initial 
design  and  refinement.  Each  of  proposed  steps  needs  to  be  performed  several  times, 
but  each  succeeding  analysis  should  be  done  more  quickly  because  the  procedure  is 
known  and  the  number  of  unchanging  performance  variables  should  be  increasing 
between  iterations.  Typically,  two  or  three  passes  through  the  substeps  will  result  in 
convergence  to  a  solution.  The  relative  importance  of  each  step  toward  system 
performance  becomes  obvious  through  experience  and  careful  documentation  of  the 
entire  analysis. 


The  following  five  steps  include  three  that  represent  the  major  categories  of 
physical  database  structure  design  and  two  that  involve  constraints  and  program 
design. 

STEP  1:  STORED  RECORD  FORMAT  DESIGN.  Assuming  that  the 
logical  record  structure  has  been  defmed,  this  process  addresses  the  problem  of 
formatting  stored  data  by  analysis  of  the  characteristics  of  data  item  types,  distribution 
of  their  values,  and  their  usage  by  various  applications.  Decisions  on  redundancy  of 
data,  derived  versus  explicitly  stored  values  of  data.and  data  compression  are  made 
here. 

Certain  data  items  are  often  accessed  far  more  frequently  than  others,  but 
each  time  a  particular  piece  of  data  is  needed,  the  entire  stored  record,  and  all  stored 
records  in  physical  block  as  well,  must  be  accessed.  Record  partitioning  defines  an 
allocation  of  individual  data  Items  to  separate  physical  devices  of  the  same  or  different 
type,  or  separate  extents  on  the  same  device,  so  that  total  cost  of  accessing  data  for  a 
given  set  of  user  applications  is  minimized.  Logically,  data  items  related  to  a  single 
entity  are  still  considered  to  be  connected,  and  physically  they  can  still  be  retrieved 
together  when  necessary.  An  extent  is  a  contiguous  area  of  physical  storage  on  a 
particular  device. 

STEP  2:  STORED  RECORD  CLUSTERING.  One  of  the  most  important 
physical  design  considerations  is  the  physical  allocation  of  stored  records,  as  a  whole, 
to  physical  extents.  Record  clustering  refers  to  the  allocation  of  records  of  different 
types  into  physical  clusters  to  take  advantage  of  physical  sequentiality  whenever 
possible.  Analysis  of  record  must  take  access  path  configuration  into  account  to  avoid 
access- time  degradation  due  to  new  placement  of  records. 

Associated  with  both  record  clustering  and  record  partitioning  is  the  selection 
of  physical  block  size.  Blocks  in  a  given  clustered  extent  are  influenced  somewhat  by 
stored  record  size,  but  also  by  storage  characteristics  of  the  physical  devices. 
Furthermore,  larger  blocks  are  typically  associated  with  sequential  processing  and 
smaller  blocks  with  random  processing.  Thus,  we  see  that  although  block  size  is 
closely  related  to  clustering,  it  is  also  dependent  on  access  path,  type  of  applications, 
and  hardware  characteristics.  Consequently,  choice  of  block  size  may  be  subject  to 
considerable  revision  during  an  iterative  design  process. 

STEP  3:  ACCESS  METHOD  DESIGN.  An  access  method  provides  storage 
and  retrieval  capabilities  for  data  stored  on  physical  devices,  usually  secondary  storage. 


The  two  critical  components  of  an  access  method  are  storage  structure  and  search 
mechanisms.  Storage  structure  defines  the  limits  of  possible  access  paths  through 
indexes  and  stored  records,  and  the  search  mechanisms  define  which  paths  are  to  be 
taken  for  given  applications.  Intrarecord  design  and  device  allocation  aspects  of 
storage  structure  are  not  used  here,  whereas  index  design  and  interrecord  connections 
are  quite  relevant. 

An  attribute  is  an  item  type  it  may  be  used  as  a  primary  key,  secondary  key, 
or  nonkey.  A  primary  key  uniquely  defines  a  record.  A  secondary  key  is  an  attribute 
used  as  an  index  to  records,  but  it  does  not  uniquely  identify  those  records.  A  nonkey 
is  an  attribute  that  is  not  used  as  a  primary  or  secondary  key  for  indexing  or  other 
search  mechanism  for  records. 

Access  method  design  is  often  defined  in  terms  of  primary  and  secondary 
access  path  structure.  The  primary  access  paths  are  associated  with  initial  record 
loading,  or  placement,  and  usually  involve  retrieval  via  the  primary  key.  Individual 
files  are  first  designed  in  this  manner  to  process  the  dominant  application  most 
efficiently.  For  the  same  reason,  physical  databases  may  require  several  primary  access 
paths.  Secondary  access  paths  include  interfile  linkages  and  alternate  entry-point 
access  to  stored  records  via  indexes  on  secondary  keys.  Access  time  can  be  greatly 
reduced  through  secondary  indexes,  but  at  the  expense  of  increased  storage  space 
overhead  and  index  maintenance.  Step  1  -  3  are  controlled  by  our  DBMS. 

STEP  4:  INTEGRITY  AND  SECURITY  CONSIDERATIONS.  As  in 
implementation  design,  trade-offs  among  integrity,  security,  and  efficiency  requirements 
must  be  analyzed. 

STEP  5:  PROGRAM  DESIGN.  The  goal  of  physical  data  independence,  if 
met,  precludes  application  program  modifications  due  to  physical  structure  design 
decisions.  Standard  DBMS  routines  should  be  used  for  all  accessing,  and  query  or 
update  transaction  optimization  should  be  performed  at  the  systems  software  level. 
Consequently,  application  program  design  should  be  completed  when  the  logical 
database  structure  is  known.  When  physical  data  independence  is  not  guaranteed, 
program  modification  is  likely.  For  example,  a  program  based  on  a  navigational  access 
method  would  have  to  be  radically  changed  if  entry-point  access  methods  were 
introduced  for  the  first  time  during  the  physical  database  design  phase. 

Design  decisions  are  also  required  in  other  areas,  many  of  which  are  quite 
system  dependent.  Some  examples  are  selection  of  butter  pool  size,  redundancy  of 


stored  records,  and  differential  files.  These  issues  appear  to  be  equally  important  and 
difficult  to  analyze  for  both  physical  database  structure  and  file  design. 
(Ref.  9:  pp.169,170] 

D.  NORMALISATION 

1.  Introduction 

By  now  we  have  examined  several  aspects  of  database  systems  in  general  and 
relational  systems  in  particular.  But  we  have  not  yet  considered  a  very  fundamental 
question,  namely:  Given  a  body  of  data  to  be  represented  in  a  database,  how  do  we 
decide  on  a  suitable  logical  structure  for  that  data?  In  other  words,  how  do  we  decide 
what  relations  are  needed  and  what  their  attributes  should  be?  This  is  the  database 
design  problem.  The  topic  of  this  section,  normalisation  theory,  is  basically  a 
formalisation  of  simple  ideas  such  as  this  one-a  formalisation  that  has  practical 
application  in  the  area  of  database  design. 

Before  going  any  further,  we  should  stress  the  fact  that  designing  a  database 
can  be  an  extremely  complex  task.  Normalisation  theory  is  a  useful  aid  in  design 
process,  but  it  is  not  a  panacea.  Anyone  designing  a  relational  database  is  advised  to 
be  familiar  with  the  basic  techniques  of  normalisation  as  described  in  this  section,  but 
we  certainly  do  not  suggest  that  the  design  should  be  based  on  normalisation  principles 
alone. 

2.  Functional  dependence 

A  functional  dependency  is  a  relationship  between  attributes.  Attribute  Y  is 
said  to  be  functionally  dependent  on  attribute  X  if  the  value  of  X  determines  the  value 
of  y.  Another  way  of  saying  this  is  that  if  we  know  the  value  of  X,  we  can  determine 
the  value  of  Y. 

For  example,  as  it  is  shown  in  Figure  4.4,  attributes  NAME  and  BIRTH  of 
relation  BASIC  are  each  functionally  dependent  on  attribute  MSN  because,  given  a 
particular  value  for  MSN,  there  exists  precisely  one  corresponding  value  for  each  of 
NAME,  BIRTH  and  RANK.  In  symbols,  we  have 

PERSON.  MSN  -♦  PERSON.  NAME 
PERSON.  MSN  -♦  PERSON.  BIRTH 
PERSON.  MSN  -♦  PERSON.  RANK 
PERSON.  MSN  -♦  PERSON. SPECIALTY 
or,  more  succinctly 

PERSON.  MSN  -►  PERSON.  (NAME,  BIRTH,  RANK,  SPECIALTY). 


PERSON(MSN  ,Name  .Birth) 
key  :  MSN 


NAME 
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SPECIALTY 
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Jae  Park 
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Sin  Yang 
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Jung  Kim 
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ASSIGNMENT Name, Unit, Position, S.date) 
key  :  UNIT,  POSITION 
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Jae  Park 
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Sam  Kim 
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Intelligence  officer 

86.5.4 

Gun  Hong 
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FAMILY ( MSN , S_Name , S.S  SN , NOD ) 
key  :  MSN 
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SPOUSE  NAME 

SPOUSE  SSN 
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Kyung  Bang 

1111-222 

166720 

Eun  Park 

2222-333 
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Mi  Chun 

3333-444 

Figure  4.4  Relational  view. 
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The  statement  'PERSON. MSN  -♦  PERSON.NAME'  is  read  as  "attribute 
PERSON.NAME  is  functionally  dependent  on  attribute  BASIC.MSN",  or, 
equivalently,  "attribute  PERSON.MSN  functionally  determines  attribute 
PERSON.NAME".  We  also  introduce  the  concept  of  full  functional  dependence. 
Attribute  Y  is  fully  functionally  dependent  on  attribute  X  if  it  is  functionally  dependent 
on  X  and  not  functionally  dependent  on  any  proper  subset  of  X.  For  example,  in  the 
relation  FAMILY,  the  attribute  NOD  is  functionally  dependent  on  the  composite 
attribute  (  MSN,  SPOUSE  NAME  );  however,  it  is  not  fully  functionally  dependent  on 
this  composite  attribute  because,  of  course,  it  is  also  functionally  dependent  on  MSN 
alone. 

On  the  other  hand,  attribute  NOD  is  fully  functionally  dependent  on  the 
composite  attribute  (  MSN,  S_SSN  ). 

The  objectives  of  normalisation  are: 

•  to  make  it  feasible  to  represent  any  relation  in  the  database 

•  to  obtain  powerful  retrieval  algorithms  based  on  a  simpler  collection  of 
relational  operations  than  would  otherwise  be  necessary 

•  to  free  relations  from  undesirable  insertion,  update,  and  deletion  dependencies 

•  to  reduce  the  need  for  restructuring  the  relations  as  new  types  of  data  are 
introduced 

•  to  make  the  collection  of  relations  neutral  to  the  query  statistics,  where  these 
statistics  are  liable  to  change  as  time  goes  by. 

[Ref.  10:  p.47] 

3.  Normal  form 

Normalisation  theory  is  built  around  the  concept  of  normal  forms.  A  relation 
is  said  to  be  in  a  particular  normal  form  if  it  is  satisfies  a  certain  specified  set  of 
constraints.  The  real  world  with  entities  and  their  properties  displays  a  multitude  of 
entity  relationships  which  can  be  expressed  in  the  form  of  two-dimensional  tables  or 
relations.  These  relations  will  in  general  be  unnormalised,  that  is,  they  may  contain 
repeating  groups  whose  presence  creates  serious  access  problems  leading  to  reduction 
in  data  independence.  A  relation  may  also  contain  nonprime  attributes  with  partial 
and  indirect  dependence  on  the  candidate  keys.  These  undesirable  associations  are 
removed  from  a  relation  by  normalisation  can  be  defined  as  a  step-by-step  reversible 
process  for  transforming  an  unnormalised  relation  into  relations  of  progressively 
simpler  structures.  Since  the  process  is  reversible,  no  information  is  lost  during  the 
transformation.  Codd  has  defined  three  stages  of  normalisation  known  as  the  first 


{INF)*  second  (2NF),  and  third  (3NF)  normal  forms  corresponding  to  the  three  types 
of  undesirable  association  discussed  above,  namely,  the  eiemination  of  the  repeating 
groups,  partial  dependence  and  indirect  dependence.  The  levels  of  normalisation 'are  ■ 
shown  in  Figure  4.6.  (Ref.  8:  p.  135] 


Figure  4.6  Three  levels  of  normalisation. 
a.  First  normal  form 

First  normal  form  is  the  starting  point,  that  is,  all  relations  are  in  first 
normal  form.  An  unnormalised  relation  is  transformed  into  INF  by  splitting  the 
relation  into  two,  one  for  the  repeating  groups  and  the  other  for  the  rest.  Consider  the 
relation  CAREER. 


CAIEH(  Mil ,  IAIK ,  HAKE  ,UK1T ,  JOB ,  LOCATION ,  8_J)ATE ,  I_DATE ) 
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Figure  4.7  An  unnormalised  relation  with  repeating  group. 

In  order  to  select  a  specific  person  who  is  most  proper  for  a  specific 
position  (or  job);  his/her  career  is  very  important.  In  that  case,  unnormalisation  can 
be  made  easily  as-it  is  shown  in  Figure  4.7.  This  clearly  unnormalised  relation, 'since  it 
includes  the  repeating  groups  of  item  code.  This  relation  is  transformed  into  first 
normal,  form  by  splitting  it  into  two  relations  PERSON  and  JOB'  as  it  is  shown  in 
Figure  4.8 

b.  Second  normal  form 

As  it  is  shown  in  Figure  4.6,  partial  dependence  is  removed  from  INF  in 
2NF.  The  second  normal  form  is  formally  defined  in  terms  of  what  is  called  functional 
dependence.  A  normalised  relation  is  said  to  be  in  the  second  normal  form  if  all  its 
nonprime  attributes  are  fully  dependent  on  each  candidate  key,  in  other  words,  if  non 
prime  attributes  do  nor  show  any  partial  dependence  on  the  candidate  keys.  In  Figure 
4.7,  the  attribute  JOB  is  fully  functional  dependence  on  the  collection  of  domain  (MSN 
+  UNIT).  But  the  LOCATION  is  independent  of  the  MSN  and  is  therefore  only 
partially  dependent  on  the  key  (MSN  +  UNIT).  Finally  the  2NF  is  shown  in  Figure 
4.9. 

c.  Third  normal  form 

As  it  is  shown  in  Figure  4.6,  indirect  dependence  is  removed  from  2NF  in 
3NF.  A  normalised  relation  is  said  to  be  in  third  normal  form  if  all  its  nonprime 
attributes  are  fully  fiinctionally  and  directly  dependent  on  each  candidate  key.  To 
demonstrate  transitive  dependence, 
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'  Figure  4.8  Relations  in  INF  of  Figure  4.7. 

Let  us  consider  relation  MEMBER  (Figure  4.l0)containing  Squadron, 
Pilot_na(ne(P_NAME)f  Quantity  of  squadron(QOS),  Rank.  If  SQ  is  the  candidate  key 
then  this  relation  is  not  in  3NF,  since  the  nonprime  attributes  RANK  is  not  directly 
dependent  on  SQ.  They  are  dependent  on  P_NAME,  which  is  dependent  on  SQ.  We 
convert  this  into  third  normal  form  by  splitting  as  shown  in  Figure  4.1 1. 

Transitive  dependence  causes  update  problems  similar  to  those  caused  by 
partial  dependence.  Therefore  ail  relations  must  be  expressed  in  3NF.  On  optimal 
third  normal  form  is  defined  as  the  minimum  number  of  relations  that  can  express  the 
original  unnormalised  relation. 

d.  Fourth  and  fifth  normal  form 

Fourth  and  filth  normal  forms  deal  with  multivalued  facts.  A  multivalued 
fart  may  correspond  to  a  many  to  many  relationship  or  to  a  many-to-one  relationship. 
Under  fourth  normal  form,  a  record  type  should  not  contain  two  or  more  independent 
multivalued  facts  about  an  entity.  In  addition,  the  record  must  satisfy  third  normal 
form;  Fifth  normal  form  deals  with  cases  where  information  can  be  reconstructed  from 
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Figure  4.9  Relations  in  2NF  of  Figure  4.7. 

smaller  pieces  of  information  which  can  be  maintained  with  less  redundancy.  Roughly 
speaking,  we  may  say  that  a  record  type  is  in  fifth  normal  form  when  its  information 
content  can  not  be  reconstructed  from  several  smaller  record  types,  i.e.,  from  record 
types  each  having  fewer  fields  than  the  original  record.  Fifth  normal  form  does  not 
differ  from  fourth  normal  form  unless  there  exists  a  symmetric  constraint.  One 
advantage  of  fifth  normal  form  is  that  certain  redundancies  can  be  eliminated. 

We  discuss  two  additional  normal  forms  very  briefly  here,  in  order  to  give 
some  idea  as  to  how  normalisation  research  is  continuing. 
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Figure  4.1 1  The  relations  of  Figure  4. 10  in  3NF. 

E.  SCHEMA  DESIGN 
1.  View  of  the  schema 

A  relational  database  is  specified  by  a  relational  schema  which  consists  of  one 
or  more  relational  subschemas.  A  relational  subschema  is  a  listing  of  a  relation  name 
and  its  corresponding  attributes.  Figure  4.12  represents  an  example  of  a  relational 
schema. 

These  views  are  then  integrated  to  form  an  enterprise  description  which 
describes  the  entire  conceptual  schema.  This  description  is  used  mainly  for 
communication  between  the  users  and  the  schema  designers.  For  each  entity  type 
identified,  a  description  of  the  entity  type  is  produced  and  the  associated  data  classes 
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PERSON  (MSN,  Im,  Ink.  Birth) 
k «y  :  MSB 

REWARD /PUNISHMENT (MSN,  A_rank,  Typ«,  Data,  Reason) 
key  r  MSN  ♦  Type  ♦  Date 
MT(MSW,  C_naae,  S.date,  E.date,  Period,  Grade) 

KEY  r  MSN  ♦  C.naae  ♦  S.date  ♦  E.date 
*  MT: MILITARY  TRAINING 


Figure  4.12  An  example  of  a  relational  schema. 

identified:  The  description  names  the  entity  type,  defines  what  it  represents,  and  lists 
its  associated  attributes. 

2.  Identifying  constraints 

In  order  to  complete  the  enterprise  description  step,  identify  constraints  on  the, 
attributes,  entity  types,  and  relationship  types.  It  seems  better  to  state  all  constraints 
explicitly  rather  than  as  inherent  constraints.  To  help  identify  constraints,  the 
following  questions  are  posed: 

(1)  what  is  the  domain  of  values  for  each  attribute? 

(2)  What  are  the  known  functiQnal  dependencies  between  attributes  of  each  entity 
type?  (it  is  discussed  in  detail  in  previous  section) 

(3)  What  are  the  keys  for  each  entity  type?  (it  is  discussed  in  detail  Chapter  III) 

(4)  What  are  the  predicate  constraints  to  be  placed  upon  the  data? 

It  is  difficult  to  arrive  at  a  set  of  constraints  that  represents  the  application 
and  its  consistent  and  feasible,  because  some  forms  of  the  constraints  are  difiicult 
understand  and  are  prone  to  misunderstandings  and  errors.  Figure  4.13  shows  domains 
and  attribute/domain  correspondence  based  on  Figure  4.12. 

F.  TRANSACTION  CONSIDERATION 

The  final  phase  of  the  enterprise  description  step  identifies  the  transaction- 
processing  requirements  of  the  organization  with  respect  to  the  enterprise  description. 


>  *  *  . 
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Domain  Naaa 


Format  and  Moaning 


MSN 

Hama 

Rank 

Birth 

A__rank 

C_name 

Grada 


positiva  intagar  lass  than  / 10000 
char(20);£ull  naaas  of  person 
.  char( 20) ; parson ' s  rank 
numeric  YYMMDD 

char ( 20) ; person ' s  rank  when  he/ she 
was  Rewarded  or  punished 
char ( 40) ; mi lit ary  training  course  name 
value  is  ’A’ , 'B* , 'C' ,or -’D’ 


Figure  4.13  An  example  of  domains  and  attribute/domain  correspondence  for  Fig  4.12. 

All.  current  and  projected  transactions  are  included.  For  each  transaction,  the  designer 
identifies  its  nature  (retrieval,  update,  delete,  insert),  its  frequency,  its  origin 
(organizational  area),  and  its  purpose,  together  with  the  point(s)  of  schema  it  affects. 
Figure  4.14  shows  a  example  of  transactions.  To  help  identify  requirements  for 
supporting  transactions,  the  following  questions  are  posed:  What  transactions  are 
required  by  each  organizational  area?  What  kind  of  access  is  required  by  each 
transaction?  What  reports  are  needed?  What  entity  types,  attributes,  and  relationship 
types  are  involved  in  each  transaction?  etc. 


Transaction:  List  all  combat  pilots  who  have' some 

flying  qualification,  capability  grade, 
and*  whoso  rank  is  captain. 

Organizational  area:  Operational  Department 
Entity: PERSON( MSN, RANK .NAME) 

COMBAT  QUALITY/ TRAINING ( MSN , UNIT , FLY_Q , C_GRADE ) 
Relationship  types: PERSON- COMBAT  QUALITY /TRAINING 

1.  Retrieve  PERSON  entity( for  MSN,  RANK,  NAME) 

2.  Retrieve  all  PERSON  entities  related  to  the 
COMBAT  QUALITY/TRAINING  via  a  PERSON- 
COMBAT  QUALITY/TRAINING 


Figure  4.14  A  simple  example  of  transaction. 
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V.  SYSTEM  ANALYSIS  FOR  RELATIONAL  DESIGN 


A-  PROBLEMS  AND  USER'S  REQUIREMENT 

First  of  alitin  order  to  design  a  database,  we  should  interview  with  user  and  and 
decide  output  which  they  need.  In  case  of  the  R.O.K  Air  Force,  we  should  classify  or 
break  down  pilots  by  their  skill, flying  hours,  flying  qualification  etc.  to  select  pilots 
who  are  best  for  specific  jobs.  This  step  consist  of  a  high-level  analysis  of  the  function 
of  an  organization.  Desired  information  of  personnel  managers  or  unit  commanders 
might  include: 

1.  List  of  all  new  commissioned  officers  in  a  specific  year  concerning  scholarship, 
major,  health  condition,  family  condition,  etc. 

2.  The  number  of  cadets  or  candidates  who  should  be  commissioned  in  the  next 
year  or  at  a  specified  year  for  each  source  organization. 

•  •  • 

3.  List  all  officers  with  each  rank  who  graduated  each  military  education  course. 

4.  Selection  of  some  officers  for  some  positions. 

5.  Summary  of  an  officer's  career  from  a  certain  previous  rank  up  to  the  current 
rank. 

6.  List  certain  officer's  rewards  or  punishments. 

7.  Present  an  information  list  for  promotion  purposes  for  each  rank  and  service 
branch,  including,  career,  result  of  fitnees  reports,  education,  rewards  and 
punishment,  health  condition,  and  the  order  of  promotion  recommendation, etc. 

8.  List  all  pilots  who  satisfy  a  certain  level  of  flying  hours,  flying  qualification  and 
a  certain  type  of  aircraft. 

All  of  information  which  may  be  required  by  personnel  managers  can  not  be 
desired,  because  different  managers  request  different  information.  Personnel  managers 
might  need  information  for  their  job  in  addition  to  that  described  above.  The  purpose 
of  requirement  analysis  is  to: 

(1)  Gain  familiarity  with  the  area  of  the  organization  to  be  modeled 

(2)  Determine  the  information  requirements  of  the  organization  without  regard  to 
constraints  other  than  the  way  in  which  the  organization  does  business. 

(3)  Represent  these  requirements  via  some  formal  modeling  technique. 

Some  major  personnel  management  aspects  of  the  Republic  of  Korea  Army  are 
promotion  selection,  job  assignment  management,  estimation  of  required  personnel 
resources  for  education,  Welfare-Morale  management  and  payroll.  We  will  consider 
and  discuss  only  the  data  concerning  the  Personal  Record,  which  is  composed  of  basic 
information,  education,  career,  etc.  Record  relationships  and  record  structure  will  be 
discussed  in  detail  in  the  next  section. 


Promotion  Selection  is  managed  by  the  Department  of  Personnel  Management. 
To  collect  the  general  personnel  data  for  promotion  selection,  2  to  10  officer'  from 
each  branch  of  the  Army  execute  the  routine  job  of  manual  data  collection  every  year. 
Since  it  is  a  manual  job,  there  exists  the  possibility  of  mistakes  and  it  is  impossible  to 
provide  the  various  kinds  of  data  necessary  to  support  promotion  selection. 

In  the  case  of  assignment  management,  it  is  difficult  to  examine  the  data  for 
matching  required  personnel  with  available  personnel  resources  for  a  specific  job  or 
position.  Therefore,  an  officer  may  be  assigned  to  an  undesired  unit  or  job  because  of 
a  subjective  decision  made  by  the  detailing  officer.  This  has  caused  a  great  deal  of 
personnel  dissatisfaction  with  job  assignments. 

The  Department  of  Personnel  Management  is  responsible  for  promotion  selection 
and  job  assignment  management.  The  Central  Financial  Corp  is  responsible  for 
payroll.  Welfare  management  is  the  responsibility  of  the  Welfare- Morale  Corps. 
Because  they  maintain  separate  data,  data  integrity  and  accuracy  is  very  low. 

As  was  mentioned  above,  the  numerous  problems  faced  are  : 

(1)  Wasting  manpower  and  time  due  to  manual  processing  causing  work  delays 

(2)  Ineffectiveness  of  work  and  non- integrated  data  processing  due  to  individual 
software  maintenance,  and  spending  a  relatively  large  amount  of  time  on  the 
maintenance  effort  and  minor  enhancements 

(3)  Lack  of  proper  supporting  system  for  decision-making 

(4)  Lack  of  data  accuracy 

Figure  5.1  shows  the  scope  and  objectives  of  the  database  that  we  have  designed  in  this 
thesis. 

B.  MODELING 

The  essence  of  database  design  is  the  representation  of  record  relationships.  The 
relationships  can  be  specified  in  a  variety  of  ways.  Data  Structure  Diagram  (DSD  also 
called  Bachman  Diagram)  is  a  simple  method  used  to  represent  overall  record 
structures.  The  single  or  double  arrow  notation  is  used  to  express  relationships 
between  records  (one-to-one,  one-to-many,  many- to- many  relation  ships),  shows  the 
relationships  among  records. 

The  relationships  are  identified  intuitively.  The  design  team  considers  potential 
relationships  among  records  that  have  been  defined.  A  relationship  may  exist  among 
three,  four  or  more  records.  At  this  point  the  design  team  must  discriminate  between 
theoretical  and  useful  relationships.  A  theoretical  relationship  can  exist  logically,  but 


67 


■w- 1 

■M 

SSa 


.  .•  A?*: 

■■'T»>5  xas 


$1 


it  System. 


*  Problem  ;  Individual  and  manual  data  processing. 


Objectives:  To  design  and  implement  a  prototype 

"  '  .  *  '  •  ■’•.•  :i  ;  •  • 

personnel  management  system. 

■  f.  Providing- proper  data  for  decision  making. 

a.  Promotion  selection. 

b.  Assignment  management. 

c.  Management  of  personnel  resources 

for  education. 

d.  Welfare  &  morale- 


Figure  5.1  Statement  of  scope  and  objectives. 

may  never  be  needed  in  practice.  Theoretical  record  rslatiooships  were  discussed  in 
emitter  III. 


In  order  to  satisfy  the  user's  requirement  we  will  derive  a  number  of  records 
from  personal  data.  Because  of  military  security,  we  will  prototype  similar  record 
model  instead  of  displaying  the  whole  personal  record.  From  the  information  in  the 
personal  record,  we  can  build  a  number  of  record  by  bundling  a  far  items  as  fields  in  a 
relational  model.  In  this  thesis,  we  will  generate  the  following  records  with  the 
undertined  field(s)  as  the  key: 

1)  MAIN  (AJT,  NAME,  ORG_B  RANCH,  C.TYPE,  BORN.DATE, 

*  BORN.PLACE) 

SN :  Service  number 


NAME:  Nam 

ORG.BRAXCH :  Oriataei  branch 
C.TYPE :  ComaMoned  type 
BORN  .DATE :  Bom  date 
BORN.PLACE 

2)  M.EDUCAT  (fifljff,  CLASS.SIZE,  START.DATE,  END.DATE, 
SNAME,  CLASS.MEAN) 

CNAME :  Com  mm 
CLASS.SIZE :  Clast  list 
STARTJDATE :  Start  data 
END.DATE :  End  data 

S. NAME :  School  name 
CLASS.MEAN  :  Clast  mean  points 

3)  EDUCATMN  (£f,  fifJUff,  B.GRADE.MEAN)  —  Intersection  record 
SN :  Scnrict  amber 

CNAME :  Com  am 
E.GRADE :  evaluation  (rods 
MEAN  :  Personal  man  points 

4)  RANK  (RANKS,  f_fl Oil.  TDATE) 

RANKS:  Rank 

P.ORDER :  Personnel  order 

T. DATE :  Data 

5)  PROMOTE  (if,  l jmtU)  —  Intersection  record 
SN  :  Service  number 

P.ORDER :  Personnel  order 

6)  AWARDPUN  (KIND,  fJUfiB.  T.DATE) 

KIND :  Kind  of  award  and  punishment 
P.ORDER :  Personnel  order 

T.DATE  :  Date 
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r>  ATJ*K  M,  tJM «D  —  Intersection  record 
SN :  Service  number 
P.ORDER :  Pmonmi  order 

•)  POINT) 

KIND  :  Kind  of  award  and  punishment 
POINT :  Points  given  by  award  and  punishment 

9)  EXPERT  (41.  BZUmU) 

SN :  Service  number 
EXPERTITLE :  Expert  title 

K>)  P.EVAl  (SN.  GRADE.  XSiXD 
.  SN :  Service  number 
GRADE :  Performance  evaluation 
T.DATE :  Date 

11)  CAREERS  (4ff.  CUN.  START.DATE,  END.DATE,  P.ORDER)  — 

SN :  Servioe  number 
SE_NO :  Serial  number 
STARJTDATE :  Start  date 
END.DATE :  End  date 
P.ORDER :  Personnel  order 

12)  UNIT  (MM  RQ.  DUTY.TITLE,  UNIT) 

SE.NO :  Serial  number 
DUTYTITIE :  Duty  title 
UNIT :  Unit 

Pbaciee  information  about  each  Add  is  in  Dau  Dictionary  in  Section  C.  of  this 


As  was  mentioned  before,  the  Reids  in  the  MAIN  record  are  fixed  items  that 
oner  need  to  be  changed.  Therefore,  as  we  can  see  in  Figure  5.2,  ail  other  records  are 
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Figure  5.2  General  view  of  record  relationship  diagram. 

centrally  related  to  the  MAIN  record.  Each  record  has  its  own  individual  purpose,  Tor 
example,  AWARDPUN  record  shows  information  about  award  or  punishment  which  a 
certain  person  was  given  ,M_EDUCAT  record  shows  training  and  education  that  a 
certain  person  has  taken.  The  reason  that  we  show  record  structure  in  the  previous 
section  is  to  make  it  easier  for  the  user  to  understand  what  record  is  needed  for  what 
purpose.  Relationships  in  Figure  5.2  should  be  reorganized  by  intersection  record  to 
divide  complex  network  record  relationships.  Reducing  a  complex  network  to  a  simple 
relation  is  discussed  in  Chapter  III.  Figure  5.3  shows  the  final  record  relationship 
design  with  intersection  record. 


Figure  5.3  Record  relationship  diagram  with  intersection  record. 

C.  DATA  DICTIONARY 

A  data  dictionary  could  be  defined  as  a  collection  of  correct  information  about 
the  words  and  terms  used  by  an  organization  to  describe  its  data.  The  term  data 
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dictionary  i*  used  to  indicate  a  collection  of  information,  that  is,  a  set  of  files  or  a 
database.  The  term  is  also  used  to  dscribe  the  mechanism  for  storing  data  in  the  fields 
and  databases,  that  is,  a  system  or  a  collection  of  computer  programs.  Data 
dictionaries  as  files  or  databases  contain  data  which  are  physically  stored  on  magnetic 
storage  media,  most  often  magnetic  disk.  Data  dictionary  systems  as  a  collection  of 
computer  programs  perform  the  functions  of  storing,  retrieving,  and  quite  often 
manipulating  and  passing  data  on  to  other  systems,  like  the  DBMS. 

The  six  major  steps  in  building  a  DDS(Data  Dictionary  System)  that  will  respond 
to  the  enterprise's  need  for  having  complete  control  over  their  data  resource  follow: 
[Ref.  ll:p.56] 

(1)  Establishing  data  naming  and  defmitiqn  standards/conventions:  This  includes 
standardization  of  data  elements,  data  items,  and  data  definition  (DD)  naming 
conventions,  program  naming  conventions,  and  job  name  naming  conventions, 
at  minimum. 

(2)  Establishing  standard  abbreviations  and  acronyms:  „  This  includes 
standardization  of  abbreviations  and  acronyms,  as  well  as  of  establishing  the 
rule  to  define  a  term  the  first  time  it  is  being  used  in  programs, 
docutnentation,reports,etc. 

(3)  Identifying  and  defining  “base  data"  data  elements:  This  includes  the 
identification  and  definition  of  product  data“  and  the  “division  or  department 
data"  of  the  enterprise,  both  of  which  are  essential  for  the  company  s 
existence. 


(4) 

(5) 


Identifying  and  defining  codes:  This  includes  identification  and  definition  of 
code  types  of  data  elements. 

Identifying,  defining,  aqd  standardizing,  input,  update,  apd  validation 
procedures:  Tms  includes  identification,  definition,  ana  standardization  of  I/O, 
update  and  validation. 


(6)  Identifying  and  defining  data  characteristics:  This  includes  the  identification 
and  definition  of  the  characteristics  of  data. 

Management  of  a  database  is  usually  a  complex  process.  It  requires  the  database 
administrator  to  keep  track  of  all  the  database  and  user  view  definitions  as  well  as  their 
use.  Data  dictionaries  have  been  developed  to  aid  the  database  administrator  in  this 
task.  The  generation  of  the  data  dictionary  which  documents  (Unctions,  data  bases, 
allowable  values,  formats,  and  their  interrelationship  should  be  initiated  at  this  point. 

The  Data  Dictionary  for  this  thesis  is  as  follow: 

Field  name:  sn 
Format:  character 


Width:  8 


Allowable  value:  less  than  100,000,000 
Description:  military  service  number  of  person, 
for  example,  77.13-3376,  73-05-5233. 
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Allowable  value:  last  name,  first  name  middle  name 

*  - 

Dcccription:  name  of  person 

Field  name:  org_branch 
Format:  diameter 
Width:  20 

Allowable  value:  infantry,  engineer, etc. 

Description:  original  branch  that  a  person  was 

assigned  when  he/ she  was  commissioned, 
sometimes  person  work  in  another  branch 
for  some  period  of  time. 


Field  name:  cjypr 
Format:  character 
Width;  Id 

Allowable  value:  ROTC,  KMA(  Korean  Military  Academy), etc. 
Description:  commistoaed  type  that  is  identified  by  the 
school  or  education  before  commision. 


Field  acme:  born.date 
Format:  character 
Width:  t 

ABowabk  value:  YYMMDD 
Description:  date  of  birth 


Width:  15 

ABoweble  value:  city  of  Seoul,  Chunnam  do,.. 

Peeeriptien;  birth  place.  a  special  city,  a  city  under  the 


direct  control  of  the  government  or  do( province) 


Width:  20 


Aflowablevahie  infantry  OBC.  engmeer  OAG.etc. 
Description:  military  course  name,  a  list  of  the  types 
of  training  required  for  a  certain  job  or 
rank. 

Fieldname:  c  grade 
Format:  character 
.Width:  15 

ABo  wbie  value  outstanding,  nnddle,etc. 

Description:  evaluation  grade  which  is  given  at  the 
end  ot every  training  or  education  course. 

Field  name:  mean 
Format: 

Width:  5 

Allowable  value  less  than  100 
Description:  personnel  average  value 

Field  name  dass_iizt 
Format:  numeric 
Width:  4 

Allowable  valueless  than  500 
Description:  number  of  students  in  class. 

class  size  is  needed  when  a  person's  position 
in  date  should  be  given  for  evaluation. 

Field  name:  start.date 
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Width* 

Allowable  value:  YYMMDD 
Description:  date  when  he/she  starts  a  certain  assigned 
job  or  education. 

Field  name:  end_date 
Format:  character 
Width:8> 

Allowable  value:  YYMMDD 

Description:  date  when  he/she  finish  a  certain  assigned  job 
or  education  course,  start  date  and  end  date 
is  needed  to  know  time  and  duration  of  person's 
assigned  job  or  education  course.  ' 

Field  name:  sname 
Format:  character 
Width:  8 

Allowable  value:  Army  infantry  schoohArray  engineer 

school,etc. 

Description:  school  name,  many  military  training  or 
education  courses  are  provided  by  many 
different  schools. 

Field  name:  classjnean 
Format*  numeric 
Width:  5 

Allowable  value:  less  than  100 
Description:  class  mean  grade 

Fieldname:  rank 
Format:  character 
Width:  20 
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Munir  nta2LT,lLT,Capt,etc. 

Description  person's  rank 

Field  name:  p_order 
Format:  character 
Width:20 

Allowable  value:  77-33  army,  78-13  army, etc. 
Description:  personnel  order  for  education,  assignment, 
promotion  etc.  p-order  has  many  different 
type  of  serial  number  for  each  type  of  order. 


Field  name  t_date 
Format:  character 
Width:  20 

Allowable  value:  YYMMDD 
Description:  date 


Field  nametkind 
Forma  tcharacter 
Width:  20 

Allowable  value: staff  of  chief  awarding,  corps  commander 
awarding,etc. 

Description:  kind  of  award  or  punishment 

Field  name:  point 

Format:numeric 

Width:4 

Allowable  value:  greater  than  -5  and  less  chan  5 
Description:  different  point  is  given  depend  on  the  type  of 
award  or  punishment 

Field  name:  expertitle 
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Description:  tome  people  have  special  qualification. 


Field  name:  grade 
Format:  character 
Width:  2 

Allowable  value:  aa,ab,ba,cb,etc. 

Description:  this  field  is  composed  of  two  grades,  the  first 
grade  is  given  by  commander  and  the  second 
grade  is  given  by  vice-commander  by  the  level 
of  job  accomplishment. 


Field  name:  dutytitle 
Format:  character 
Width:  20 

Allowable  value:  platoon  leader,company  commander, etc. 
Description:  duty  title,  some  job  or  assigned  position 
is  required  for  promotion,  duty  title  is 
needed  for  job  assignment  or  promotion  selection. 


Field  name:  unit 
Format:  character 
Width:  25 

Allowable  value:  55x  227r  2bn  5co  2pl,48x  105r  70bn,etc. 
Description:  unit  is  composed  of  divisionfx), 

regiment(r),battalion(bn),company(co),platoon(pn). 


Field  name:  se.no 
Format:  numeric 
Width:  7 

Allowable  value:  9293001, 7354023, etc. 
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Description:  aerial  number,  unique  number  is  given  to 
every  unit 


VL  DATA  BASE  IMPLEMENTATION 


A.  INTRODUCTION 

The  introduction  of  a  data  base  as  the  central  reservoir  of  data  affects  the  user 
organization  in  a  number  of  ways.  For  example,  it  changes  the  organization's  attitude 
to  data  requirements  and  management,  it  creates  new  authorities  and  it  brings  in  new 
skills.  It  also  enforces  greater  coordination  between  the  various  user  departments  and 
demands  stricter  adherence  to  standards.  A  good  implementation  scheme  should 
include  adequate  provision  to  tackle  these  problems,  in  addition  to  having  plans  for 
system  developments  and  scheduling  of  resources.  Much  of  this  would  be  planned  and 
controlled  by  the  DBA,  on  whose  ability  will  largely  append  the  success  of  the  venture 
•  provided  that  the  right  DBS  is  selected  in  the  first  place.  In  this  chapter  we  will 
discus*  these  issues:  relational  implementation  and  data  base  administration. 

B.  RELATIONAL  IMPLEMENTATION  OVERVIEW 

In  relational  systems,  data  reliability  is  provided  by  the  ability  to  construct  new 
relations  from  existing  relations  by  the  use  of  the  relational  operators.  The  relational 
operators  may  require  access  paths  to  contain  or  represent  the  derived  relations.  The 
access  paths  may  exist  in  the  system,  or  they  may  be  constructed  by  the  system  as 
required.  For  instance,  a  join  can  be  implemented  as  a  separate  file.  as  a  set  of 
pointers,  or  by  storing  the  definition  of  the  join  and  generating  it  as  needed.  However, 
no  matter  how  it  is  implemented,  the  user  is  not  aware  of  the  exact  representation  and 
does  not  really  care  what  it  is. 

Since  a  user  is  not  explicitly  aware  of  the  access  paths  in  a  relational  system,  this 
may  lead  to  the  misconception  that  relational  systems  do  not  provide  access  paths. 
This  is  far  from  true.  As  in  a  hierarchical  or  a  network  system,  a  relational  system  may 
need  specific  nature.  The  existence,  and  maintenance  of  these  access  paths  may  be 
hidden  from  the  user.  Nevertheless,  they  exist,  and  their  implementation  is  one  of  the 
hardest  design  problems  in  a  relational  system. 

Relational  systems  can  be  differentiated  according  to  how  they  represent  derived 
relations  via  access  paths.  If  they  only  store  the  definition  of  a  derived  relation,  then 
the  access  paths  corresponding  to  the  physical  implementation  of  the  derived  relation 
are  destroyed  after  every  query.  In  this  case,  content  addressability  may  be  sufficient 


to  construct  the  access  paths  as  required.  For  example,  a  join  can  be  constructed  using 
content  addressability  by  correlating  tuple  identifiers  from  the  inverted  files,  for  the  two 
relations,  according  to  the  join  condition.  On  the  other  hand,  the  system  can  retain 
and  maintain  the  access  paths  corresponding  to  the  definition  of  a  derived  relation.  In 
this  case,  the  maintenance  of  these  access  paths  can  become  very  involved. 

There  are  currently  many  commercial  DBMS  products  that  claim  to  be  relational. 
Some  are  more  relational  in  name  than  in  actuality.  The  DBMS  should  model  data  as 
tables,  and  it  should  support  SELECT,  PROJECT,  and  unrestricted  JOIN  operations. 
A  system  that  supports  restricted  JOIN  operations  falls  in  a  gray  area.  Some  people 
would  call  the  system  a  relational  system  in  spite  of  this  limitation.  Others  would  call 
it  a  tabular  system. 

Relational  DBMS  can  be  divided  into  three  groups.  One  group  is  based  on  the 
data  language  SQL,  one  on  the  data  language  QUEL,  and  one  group  contains  system 
falling  into  neither  of  these  categories.  Three  major  SQL-based  DBMS  products  are 
SQL,  DS,  System  R,  and  ORACLE.  System  R  is  a  research  system  developed  by  IBM 
for  the  study  of  relational  technology.  System  R  has  been  used  in  a  prototype  mode 
by  several  major  industrial  concerns.  SQL/DS  is  a  commercial  version  of  System  R. 

ORACLE  was  developed  for  operation  on  Digital  Equipment  Corporation  PDP 
minicomputers.  Since  its  organization,  ORACLE  has  been  converted  to  operate  on 
IBM  mainframes  as  well.  ORACLE'S  user  interface  is  based  on  SQUEL  II,  an  earlier 
version  of  SQL.  According  to  RSI,  ORACLE  will  soon  be  compatible  with  the  current 
version  of  SQL. 

QUEL  (QUEerv  Language)  is  a  data  language  like  SQL.  QUEL  is  based  on 
tuple  relation  calculus.  QUEL  is  nonprocedural  and  allows  the  user  to  process  data 
without  concern  for  physical  data  structures.  The  data  base  product  INGRES  is  based 
on  QUEL.  INGRES  operates  on  Digital  Equipment  PDP  hardware  and  runs  under 
the  UNIX  operating  system.  I  DM  500  is  also  based  on  QUEL. 

There  are  many  other  relational  DBMS.  There  is  even  a  microcomputer 
relational  product:  dBASE  II,  which  is  needed  by  Ashton-Tate.  dBASE  II  operates  on 
CP/M-based  micros.  dBASE  II  is  an  example  of  a  relational  DBMS  that  restricts  join 
operations.  The  join  columns  must  be  indexed.  [Ref.  7:  pp.437,438] 


C  IMPLEMENTATION  USING  DBASE  III + 

As  we  mentioned  before,  we  use  DBASE  III  +  to  show  the  sample  application 
program  for  prototyping  in  this  thesis.  The  Korean  military  personnel  management 
system  has  been  implemented  using  dBASE  IU+  relational  DBMS  in  appendix.  As  a 
word  processor  allows  one  to  manipulate  characters,  words,  sentences  and  pages  to 
create  a  document  that  fits  one's  needs,  dBASE  III  +  allows  one  to  work  with  fields, 
records,  and  files  to  manage  data  in  just  the  desired  manner. 

We  will  provide  basic  operations  to  implement  the  data  base  using  dBASElII  + 
in  this  section. 

1.  CREATE 

First  of  all,  in  order  to  create  a  file,  CREATE  command  is  used  as  follows: 


9 

CREATE  PARK 

Field  Name 

Type 

Width  Dec 

1 

RANKS 

Character 

20 

* 

2 

P  ORDER 

Character 

2a 

3 

TDATE 

Character 

B 

2.  USE 

A  file  called  PARK  has  now  been  created  on  the  data  base  by  1.  To  select  a 
file  to  work  with,  we  should  use  USE  command: 

.  USE  PARK 


APPEND 


RANKS 

P.ORDER 

tdate 

RANKS 

P.ORDER 

TDATE 


2nd  lieutenant 

77- 33  arty 
03/28/77 

1st  1 i eu  ten  ant 

78- 33  ere y 
04/01/78 


4.  LIST 

When  we  create  a  file  or  add  information  to  a  certain  file,  we  need  to  verity 
the' information  and  data  structure.  In  this  case,  we  use  LIST  command  to  list  a  data 
file's  contents  on  the  screen. 


.  LIST 

Record#  RANKS 

1  2nd  lieutenant 

2  let  lieutenant 


P.ORDCR 

77- 33  erey 

78- 33  erey 


.  LIST  FOR  RANKS  «  "2nd  lieutenant" 
Record#  RANKS  P. ORDER 

1  2nd  lieutenant  77-33  aray 


TDATE  ' 
03/28/77 
04/01/78 


TDATE 

03/28/77 


.  LIST  STRUCTURE 

Structure  for  databases  CtPARK.dtof 
Number  of  data  recordei  1 

Date  of  last  update  i  01/04/87 
Field  Field  Name  Type  Width 

1  RANKS  Character  20 

2  REORDER  Character  20 

3  TDATE  Character  8 

ta  Total  at  44 


1  Ult  ^ 

P.OROOR 

TDATC 

f  t  1M  U«ul«n«nl 

77-33  aray 

03/20/77 

I*  2  1st  llMUMnt 

,  70*33  aray 

04/01/70 

L  EDIT  2 

MMK  1st  titutariMt 

MiTK  .  04/01/7® 

L  Hot  1 

BUCO r#0  MMCO 

P.OM0CO 

TDATC 

I  1  *  2nI  liau tenant 

77-33  aray 

03/20/77 

_ 3  ~~ _ 

70-33  aray 

04/01/7# 

1.  LIST 

MNrtfft  MNKS 

H.OROCH 

TDATC 

t  2 nd  1  taut  an  ant 

77-33  aray 

03/28/77 

2  Mjar 

7S-33  aray 

04/01/78 

.  DCLKTC  HECOHD  2 

1  racord  dal at ad 
.  OUTLAY 

Hacordd  RANKS 

H.ORDCR 

TDATE 

2  taajor 

78-33  aray 

04/01/70 

.  MCCALL 

1  racord  ra call  ad 

.  . 

.  DISPLAY 

Maeordd  HANKS 

H.OHDER 

TDATE 

2  aajor 

78-33  army 

04/01/78 

.*  DCLKTC  ACCOAD  2 

• 

1  racard  dal at ad 
.  0X8HLAV 

Aacardd  HANKS 

H.OHDCH 

TDATE 

2  tMjor 

78-33  aray 

04/01/78 

.  HACK 

I  racard  cop lad 

* 

.  LIST 

Hacardd  HANKS 

H.OHDCH 

TDATE 

1  2nd  Uautanant 

77-33  aray 

03/28/77 

To  we  non  ti 

m.  if  k  it  a 
d  awst  be  used. 


data  file,  dBASE  111+  reserves  two  areas  of  memory 
to  use  mother  date  file  at  the  same  time,  SELECT 


tauter  i 


HUCT  2 

uaa  Patmore  imocv  promotc 

join  mum  ram c  to  Tcnmcc  roa  r.oaoca  -a->r 

2  r •certs  Jeined 

uaa  TE»**rxLi 

LIST 


S  2000* 
2  21354 


.OMta  riEuw  eN.a-HMuace 


2nd  Uwtwwt 
2nt  itsutanant 


8.  INDEX 

'  W*  can  use  INDEX  command  to  sort  a  data  file  in  a  certain  order.  If  a 
specific  item,  not  the  whole  list,  is  wanted,  then  the  FIND  command  can  be  used  to 
display  on  the  screen. 


.  IMOCX  ON  P.ORDER  TO  KIM 

100*  indexed  2 

Record*  indexed 

.  UK  PARK  INDEX  KIR 
.  WIRT 

Record#  RANKS 

P.OROCR 

TDATE 

1  2nd  lieutenant' 

77-33  arey 

03/2S/77 

2  tat  lieutenant 

7S-33  arey 

04/01/70 

.  PINO  77-13  arey 
.  DISPUAV 

Record#  AANKS 

R.OROCR 

TOATf 

1  2nd  lieutenant 

77-33  arey 

03/20/77 

•<-  v 

^  v- 

,>  ■  ■•'  .  ■*** ' 

m.  BATA  UK  AMMTtATOI 

lneceoi«incieoitqMMm,fessheiangte  thsf«lrmaiue**poitnmots.  It  is  they 
wfeeameagoorihfeferrim-acoiieaey,  sindtMnry  and  np  to  dmenees  af  dm  l>  the  file. 

|NMki|«C  la  t  4ms  bace  where  aft  aaaapaay  data  am  oamnfiy  Ml  no  single 

mm  MpIraMK  CHI  DC  sCCpCnCsDIC  fOr  VU  IfUKCDC!  uDS  fCCpOMMKj  m  CXCKvoCO  wf  Wm 

dm  Han  cdminittitriir  oa  behalf  of  the  who!*  company  with  •  view  to  preserving  the 
hMMWt  of  both  current  tad  fotum  wars.  la  addition,  tha  DBA  ic  also  responsible  for 
creating,  nfiim  and  bnpeoving  the  date  bate  and  for  providing  user  fodhtias.  For 
a  aanft  dun  hoot,  the  fonction  of  the  DBA  can  be  performed  by  aa  individual  u  a 
parr  linte  job,  but  for  a  large  data  base,  the  fonctioa  can  require  the  foO>tuae  services 
of  a  Mam  To  be  effective,  the  DBA  should  represent  a  senior  position  with  sufficient 
authority  to  arbitrate  disputes  between  the  user  departments  on  data  base  usage,  and 
•  to  bnpoee  decisions  in  case  of  deadiochs  He  should  also  be  accepted  aa  the  feral 
authority  in  all  matters  niatmg  to  the  management  of  the  data  base. 

The  fonctioa  of  the  DBA  should  bo  include  the  following  activities:  creation  of 
aa  data  base,  perfocmanoe  optimisation,  data  protection,  iporfflrcfion  ««mi 
aefbesament  of  standard*,  end  coordination  and  tha  provicion  of  the  user  fedhties. 
David  difoiss  the  reap nnribiiity  of  DBA—  foiosr 


(1)  DBA  Data  Activity  Maaamnmnt  RnsnonriMBtias 

•  provide  data  hast  standards 

•  establish  data  owner  ship,  retrieval  and  modification  rights 
e  create  end  dhsantinato  recovery  procedure 

•  riform  and  train  ucors 

•  enforce  data  activity  policy 

•  publish  and  maintain  documentation 
(Bat  7:  pJdOf 

(2)  DBA  Datahaee  Structure  Management  Responsibilities 

•  design  the  schemed) 

•  provide  design  tiperriss 

•  control  redundancy 

•  mamma  configuration  control  of  changs  requests 

•  schedule  sad  run  conllgurauon  control  meeting 

isnplesnssM  scheme  changes 
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flMtfMMl  kM,  iMh  mnfor  Amadou  hi  the  ay mm  oocreapouds  to  •  section  of  the 
Uar't  MMd  and  sdaodeo  ftw  the  mail  menu.  It  is  important  to  rand  the 
hdbMMhNi  or  the  taws  you  pita  to  use  before  you  uee  it  This  tells  you  exactly 
what  hdbuuidau  you  need  aad  where  to  And  to. 

Ham  is  also  a  chopeer  oo  tie  DIUVER  (or  main  menu)  section  of  PMS.  This  is 
vuiy  important  to  read  before  you  start  using  PMS  as  it  describes  the  actions  required 
if  you  gal  stash  in  foe  ariddte  of  a  program  aad  cannot  get  out  or  if  the  system  crashes. 

TMs  natural  is  indicated  for  urn  with  the  ISM  PC(AT).  You  have  been  provided 
3  dbhecsas:  dSASE  III+(1),  dBASE  Ill +(11),  aad  PMS.  You  must  "boot  up'  your 
ssspuur  system  (which  should  be  equipped  with  a  hard  dish)  and  then  do  the 


I.  Copy  above  diehettes  into  the  hard  disk. 

1  Type  'dbess'  (no  quotes  needed),  and  then  strike  the  return  key.  Once  the 
system  is  loaded,  you  wig  see  the  "(dot)  prompt  on  the  screen. 

3.  Type  'set  default  to  c'(no  quotes  needed)  and  then  the  return  key.  the  ‘.'will 
appear  again.  Now  you  are  ready  to  use  the  personnel  management  database 
system!  PMS). 

4.  At  this  point,  type  ‘do  driver! no  quotes  needed)  followed  by  a  carriage  return. 
After  a  short  wait,  the  PMS  main  menu  will  appear  and  you  can  start  enjoying 

PMS. 

5.  You  have  to  follow  the  command  messages  which  appear  on  the  screen.  The 
various  options  of  the  mam  (Unction  of  this  system  are  specified  in  the  first 
message  (main  menu).  Enter  the  main  menu-letter  which  you  want.  This  will  be 
followed  by  another  message  menu  on  the  screen.  Select  the  menu-letter  which 
you  want,  and  follow  the  command  message  on  the  screen. 

6.  After  having  done  what  you  wanted,  you  can  return  to  the  previous  menu  by 
selecting  menu  option  *x‘. 
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*  f'r  T 


A.  MHYCt 

The  #wr  ptoyta  hu  Ihm  Amctiore  First,  it  will  ask  what  kind  of  service 
ym  regain  and  than  caM  that  fraction  your  task.  It  wii  continue  until  you  finished. 
This  Is  a  any  atraight4bnrard  menu  driven  selection  process  and  does  not  require  any 
special  information  to  use.  Second,  much  more  complicated  part  of  the  DRIVER, 
deals  with  reconstruction  of  the  Data  Base  if  the  system  crashes  in  the  middle  of  a 
session.  The  DRIVER  always  stores  a  copy  of  every  user  interaction  in  a  file  called 
CRASH.TXT.  This  file  a  deleted  at  the  end  of  every  normally  terminated  run. 
However,  if  the  run  were  to  abort  abnormally  this  file  would  allow  you  to  recreate 
every  step  and  check  the  contents  of  the  Data  Base  for  accuracy.  Finally,  if  you 
chaafe  the  data  in  all  system  programs,  the  data  is  used  continuously  alter  changing. 

The  DRIVER  program  presents  the  main  menu  on  the  screen!  Figure  7.1).  If  you 
aie  unfamiliar  with  the  7  options  presented  in  the  main  menu,  refer  to  the  preliminary 
information  section  so  that  you  can  refresh  yourself  on  what  each  option  is  all  about. 
Select  an  option  from  I  to  7.  Upon  option  selection  please  refer  to  the  respective 
section  you  have  just  selected. 


i  c 


iiUiJ 


NMt 


MtlMMtiHtM 


ALLOTHSNT  TAILS . 

■.  LIST INS. 

Any  sur y  that  rt^ilrn  *  llttinf  mr  Incarnation 

C.  MKMTIpartml  record  card). 

D.  UPDATE. 

I.  EDIT . 

A.  DICTIONARY. 

S.  CHANat  OATS. 

I.  BUT. 


OATS 

01/31/17 


TIMS 

0*1 1*1 23 


INFORMATION 


UPDATED  iV 


I  Sntsr  sol  action  I  A  •  B,  or  I  to  l.n  i  .  . *  1  IHBMttHliaiiMttWWiittUHMdtiaWaiH 


Figure  7.1  Officer  personnel  management. 


Figure  7.2  Personnel  allotment. 


C  LISTING 

The  fating  fhnetion  allows  you  to  obtain  listing  or  information  on  officers.  You 
can  reach  this  section  by  entering  an  "B‘  at  main  PMS  menu.  It  is  designed  to  cycle 
back  to  the  main  LISTING  Menu  until  all  of  your  queries  are  answered.  It  will  then 
return  you  to  the  main  PMS  menu.The  available  listings  are  shown  the  following 
screen!  Figure  7.3).  Please  pay  close  attention  to  the  section  on  what  information  you 
need  to  access  each  report. 

1.  Select  eptian  to  fat  ai  officers 

As  the  title  suggests  this  section  will  provide  a  list  of  all  officers  in  the  data 
file.  The  output  is  shown  below  ( Figure  7.4). 

2.  Select  eptian  T  to  fat  aM  new  officers  lor  assignment 

This  section  provides  a  list  of  all  new  officers  for  assignment.  The  following 
screeolFigure  7.5)  will  appear.  In  order  to  use  this  section  you  will  need  the  personnel 
order  of  the  new  officer  exactly  as  it  is  shown  in  the  database.  A  complete  list  ot  the 


Figure  7.3  Submenu  of  listing. 


1  Mi  or 

20001 

jun«, Ja*  h* 

K.H.M33 

2  aajar 

21SS4 

kta.aa*  nam 

K.I1.M33 

3  Mir 

390*73 

jaa,Ma  Joan 

3>..lt.Aai3 

4  Mjr 

22222 

kan*,aaan  a* 

K.  It.  A*  33 

S  Mjar 

2348* 

aark.jaa  tan 

K.I1.M33 

Praam  any  kay  la  a 

■Mima. . . 

Figure  7.4  List  all  officers. 

personnel  order  can  be  found  in  the  Appendix  of  this  thesis.  You  must  enter  the 
personnel  order  exactly  as  shown  or  the  system  will  not  be  able  to  match  the  correct 
personnel  order  and  will  return  an  error  message.  The  outputs  are  shown  below 
(Figure  7.6). 


92 


ta/iMk  mi 


Figure  7  J  Query  to  Rad  out  coaimwiioood  officers. 


ta/it/at 


Nrt.jM 


Figure  7.6  List  new  commissioned  officers. 

3.  Select  igtlea  *C*  to  list  el  educated  officers 

It  will  provided  a  list  of  the  officers  educated  in  the  military  school.  The 
following  screen( Figure  7.7)  will  appear.  In  order  to  use  this  section  you  wilt  need  to 
enter  the  military  education  course  name  in  the  Appendix  exactly.  The  outputs  are 
shown  below(  Figure  7.8). 


v.v.v; 


»  «  • 


Figure  7.7  Quary  education  results  of  each  officer. 


ta/t*re» 

-a-  -  ~ 

LIST 

1  MW«  cvaumtion 

2ISB4  U«,IM  IMS 

ln4«Mry  ■.•.e«234 

no*  parft.jM  MM 

IklaRtry  •.b.c«234 

■on  i— jm* 

IMMry  *.4.cI2M 

Figure  7.8  List  education  results  of  each  officer. 

4.  Select  option  to  list  all  officers  for  proowtioa  test 

This  will  provide  a  list  of  all  officers  for  the  promotion  test.  The  following 
screen(  Figure  7.9)  will  appear.  In  order  to  use  this  section  you  will  need  the  promotion 
year  and  rank  (in  the  Appendix)  exactly.  The  outputs  are  shown  below(Figuie  7.1D). 


Figure  7.9  Query  to  find  out  all  officers  for  promotion  test. 


Pag*  No.  1 

01/31/87 


LIST  ALL  OFFICERS  FOR  PROMOTION  TEST 


SEVICE 

NAME 

COMMISSONED  PERSONNEL 

NUMBER 

TYPE 

ORDER 

20001 

Jung,  in  ho 

K.M.A433 

84-33  aray 

21334 

klataaa  naa 

K.H.AB33 

84-33  aray 

Prn>  any  key  to  continue... 


Figure  7.10  List  all  officers  for  promotion  test. 

D.  REPORT  (  PERSONNEL  RECORD  CARD  ) 

The  REPORT  function  allows  you  to  obtain  detailed  information  ot 
officer's  history.  You  can  reach  this  section  by  entering  a  *C"  at  the  Turn  P\is  ic  > 
You  will  remain  in  the  REPORTS.PRG  unull  all  of  your  kjueries  are  antwereu  i  • 
then  return  you  to  the  main  PMS  menu.  The  following  screen*  I  $  t*r 
appear.  In  order  to  use  this  section  you  will  need  the  service  number  k-i 
shown  in  the  data  base.  A  complete  list  vit  the  \crM».e  ■nitntH--  . ■  *t- 

Appendix  of  this  thesis.  The  outputs  are  shown  hclowi  I  lgurt 
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2/2 


ID-A181  (62 
UNCLASSIFIED 


APPLICATION  OF  A  DATABASE  SVSTEN  FOP  KOREAN  AILITAPV 
PERSONNEL  HANAQEHENTCU)  NAVAL  POSTGRADUATE  SCHOOL 
HONTEREV  CA  S  N  KIN  ET  AL.  AAR  87 

F/B  5/1 


il/IMI  M««*i 


UM  i 


U  Mill 


Figure  7.11  Query  to  And  out  personnel  xordcard. 


im*m* rv 


Figure  7.12  Personnel  record  card. 


UPDATE  AMD  EDIT 
Tin  UPDATE  and  EDIT 


MTE  and  EDIT  Amctioa  alow  yon  to  chaitft  Adds  in  any  file.  It  also 
dw  So  that  wno  affected  by  your  changes.  It  is  vary  important  that 
wMi  your  rhsngss  bacauaa  tha  impact  of  a  mistake  could  have  wide 
■adorn.  You  can  ranch  this  sacuoo  by  entennf  'D'  and  E"  for  adding 
at  tha  nain  PMS  menu.  The  update  and  edit  program  are  almost  the 
an.  This  wM  be  an  explanation  of  the  EDIT  function  only.  The 
enuu( Figure  TI3)  will  appear  on  the  screen. 


Figure  7.13  Submenu  for  changing  personnel  records. 

L  Select  optfoe  'A*  to  change  personnel' records 

This  wilT  allow  you  to  change  any  fields  in  the  MAIX.DBF  file.  You  must  be 
eery  careftil  when  changing  the  service  number  because  the  other  files  will  be  changed 
to  this  menu  value  as  well  as  the  MAIN  file.  The  following  screenf  Figure  7.14)  will 
appear.  You  must  know  the  service  number.  Failure  to  do  so  may  result  in  the  wrong 
information.  After  entering  the  service  number,  the  following  screenf  Figure  7.15)  will 
appear,  and  then  you  may  enter  new  data  or  change  data. 


Figure  7.14  Query  to  change  personnel  records. 


97 


«ews 

ea  mmm  >  nN* 

NRHEi kin, son  naa 

OMIt 

ML  BMNCMt  Infantry 

cowtr 

MUON  TYffi  K.H.A033  M 

JRN  OATCl 07/21 /S4  BORN  PLACE i chunnaa  do 

Characters  Loft  Ri«ht 

OCLCTe 

Char  act  art  OIL 

RECORD 

Previous  Racordi 

PgUp 

Uordi  HOHK  KNO 

Fialdt  ~V 

Rant  Racordi 

PgDn 

Pialdi  Up  Down 
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Figure  7.15  Screen  for  changing  personnel  records. 

2.  Selection  option  MB~  to  change  expert  records 

This  will  allow  you  to  change  any  files  in  the  EXPERT.DBF  file.  The 
following  screen(  Figure  7.16)  will  appear.  You  must  know  the  service  number  and 
expert  title,  failure  to  do  so  may  result  in  the  wrong  information.  After  entering  the 
service  number  and  expert  title,  the  screen  will  be  displayed  as  followsf  Figure  7.17), 
and  then  you  may  enter  or  change  data. 


KBIT  (XPERT  RECORD 


12/ 10/D*  02 1 30i  02 


K«lit  for  what  aarvlea  nuaoar  <  or  prooa  RETURN  to  OHit> 


Figure  7.16  Query  to  change  expen  records. 
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Figure  7.17  Screen  for  changing  expert  records. 


Figure  7.18  Submenu  for  changing  military  education  results. 
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Wftm  erfrt  eptfea  "A"  front  the  aafttary  idacwioa  wb-mcnu.  you  win  m 
H  Maariag  7.  If).  TMi  trtt  allow  you  to  change  any  fUet  m  the 

MJM.CAT JMMF  St  Yw  mm  know  the  aifitary  education  count  nankin 
AffOdh)  tweedy.  After  entering  the  warn  mm,  the  following  screcn( Figure  7.20) 
irii  appear,  a Mi  then  eater  or  change  data. 
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Figure  7.19  Query  to  change  military  education  results. 
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Figure  7.20  Screen  for  changing  military  education  results. 
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If  ye*  ariect  pattern  “W  from  the  saBkary  education  snh  menu.  tov  wiD  m 
i»  MM|  m—(B|bw  7.21).  This  wifi  altar  you  to  add  ami  change  any  Helds  m 
*0  EDCCATMN.  WF,  too  float  knew  the  military  education  courae  name  and 
sendee  wntar  (in  Appendix)  exactly.  After  entering  the  courae  name  and  service 
number,  ilia  Mheiat  screen*  Figure  7.22)  win  appear  on  the  screen,  and  then  you  may 


Figure  7.2t  Queries  to  change  personal  education  result. 
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Figure  7.22  Screen  for  changing  personal  education  results. 
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Figure  7.24  Query  to  change  promotion  record. 
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Figure  7.25  Screen  for  changing  for  promotion  record. 


If  you  select  option  "B"  from  the  add  and  edit  promotion  record  sub-menu, 
you  will  see  the  following  screen(  Figure  7.26).  This  will  allow’  you  to  add  and  edit  any 
fields  in  the  PROMOTE.DBF.  You  must  know’  the  service  number  and  promotion 
order  (in  Appendix)  exactly.  After  entering  the  service  number  and  promotion  order, 
the  following  screen(Figure  7.27)  will  appear,  and  then  you  may  enter  or  change  data. 


'<  ■*»  »M  1 


•ii  V  ‘  <  ' 


Figure  7.27  Screen  for  changing  personal  promotion  record. 

5.  Select  option  "E"  to  change  award  and  punishment  records 

This  will  allow  you  to  change  award  and  punishment  records.  The  following 
submenu  screen!  Figure  7.28)  will  appear  on  the  screen. 

If  you  select  option  "A"  from  the  award  and  punishment  sub-menu,  you  will 
see  the  following  screen!  Figure  7.29).  This  will  allow  you  to  add  and  change  any  fields 
in  the  A_P_P.DBF  you  must  know  the  award  and  punishment  name  (in  Appendix) 
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Figure  7.28  Submenu  for  changing  award  and  punishment  records.. 


exactly.  After  entering  the  award  and  punishment  name,  the  following  screen 
(Figure  7.30)  will  appear,  and  then  you  may  enter  or  change  data. 


Figure  7.29  Query  to  change  award  and  punishment  points. 
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Figure  7.30  Screen  for  changing  award  and  punishment  points. 

if  you  select  option  "B"  from  the  award  and  punishment  sub-menu,  you  will 
see  the  following  screen( Figure  7.31).  This  will  allow  you  to  add  and  edit  any  fields  in 
AWARDPUN.DBF  file.  You  must  know  the  personnel  order  (in  Appendix)  exactly. 
After  entering  the  personnel  order,  the  following  screen(  Figure  7.32)  will  appear,  and 
then  you  may  enter  or  change  data. 


Figure  7.31  Query  to  change  award  and  punishment  record.. 
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Figure  7.32  Screen  for  changing  award  and  punishment  record. 

If  you  select  option  "A"  from  the  award  and  punishment  sub-menu,  you  will 
see  the  following  screen!  Figure  7.33).  This  will  allow  you  to  add  and  edit  any  fields  in 
A_P_MN.DBF  file.  You  must  know  the  service  number  and  personnel  order(in 
Appendix)  exactly.  After  entering  the  service  number  and  personnel  order,  the 
following  screen!  fig  7.34)  will  appear,  and  then  you  may  enter  or  change  data 


Figure  7.33  Query  to  change  personal  award  and  punishment. 


Figure  7.34  Screen  for  changing  personal  award  and  punishment  record. 
6.  Select  option  ”F*  to  change  performance  evaluation  record 


This  will  allow  you  to  add  and  change  any  fields  in  the  P_EVAL.DBF  file. 
The  following  screen(  Figure  7.35)  will  appear. 

You  must  know  the  service  number  and  evaluation  date,  failure  to  do  so  may 
result  in  the  wrong  information.  After  entering  the  service  number  and  evaluation 
date,  the  following  screen( Figure  7.36)  will  appear,  and  then  you  may  enter  or  change 
data. 


Figure  7.35  Queries  to  change  performance  evaluation  records. 
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evaluation  records. 


Fifure  T37  Queries  to  chanfe  personal  assignment  record. 


MTV  TIMi 


III 


FifM  7.11  Screen  for  changing  personal  assignment  record. 

F.  DATA  DICTIONARY 

The  ohms  mm  of  the  PMS  iynw  (OPTION  F)  allows  you  to  access  the  data 
inisasrT-  Through  the  dictionary  menu,  you  can  find  out  what  a  variable  name  is 
and  beer  to  eaear  it  mto  the  computer  (option  A),  find  out  the  structure  of  commonly 
need  data  Ah  (option  •),  find  out  where  a  vanaMe  is  used  in  these  files  and  modules 
(optioa  C)  and  find  out  other  (natures  of  the  dictionary  with  an  exit  back  to  main  PMS 
nuna  (option  DV  iy  doing  this,  you  hone  more  interactive  flexibility  when  using  the 
syseeaa.  You  nmet  «V  hone  seme  idea  about  what  a  variable  is  named  before  you  can 
Ket  the  (He  structure  and  retrieve  the  exact  variable  name.  The  following  screen 
(Figure  7.19)  wifi  appear. 

I.  Safest  option  *A*  te  find  out  ehmeut  mom  la  the  (fie 

This  allows  you  to  ask  questions  about  element  and  how  they  are  entered  into 
the  composer.  For  example,  you  know  the  variable  name  or  at  least  a  few  letters  of  it. 
You  wdl  see  DO  YOU  WANT  A  PRINTOUT?  Y  OR  N  If  you  desire  a  hardcopy 
printout  of  the  informathm,  you  would  ready  your  printer  at  this  time  and  enter  a 
capital  Y.  If  you  do  not  desire  a  printout,  enter  The  information  you  will  receive 
witt  he  ehmeut  name,  fun  name,  type,  frequency  of  update  and  comments.  If  you 
entered  a  lew  letters  of  the  name,  you  may  get  several  element  names  and  values.  AH 
of  the  clement  names  win  appear  fust,  then  aU  of  the  full  names  will  appear  second, 
and  so  forth.  You  can  then  choose  the  one  you  want  and  get  a  clean  copy  of  the  exact 
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Figure  7.39  Submenu  of  data  dictionary. 

element  name,  if  desired.  REQUIRED  INFORMATION-  The  element  name  or  at 
least  a  few  letters  of  it.  You  may  obtain  this  first  through  dictionary  option  2  if  you 
know  what  file  it  is  used  in. 

2.  Select  option  T  to  find  out  used  data  files 

This  allows  you  to  discover  how  certain  files  are  structured.  The  options  are 
alphabetic  and  they  represent  the  commonly  used  data  files  in  PMS.  You  will  see  the 
following  screen  (Figure  7.40). 

You  will  then  enter  the  letter  of  your  selection.  If  you  enter  something  besides  the 
menu  options,  you  will  see  the  same  screen.  If  you  want  to  leave  this  portion  of  the 
dictionary,  select  the  letter  for  'X'.  You  will  then  be  asked  if  you  want  a  printout.  If 
you  do,  you  ready  your  printer  at  this  time,  and  then  enter  a  capital  Y.  If  you  do  not 
want  a  printout,  type  N. 

This  option  allows  you  to  discover  the  exact  variable  names  (listed  as  fields) 
used  in  a  file. 

3.  Select  option  "Cm  to  find  out  used  modules 

This  portion  of  the  dictionary  allows  you  to  make  queries  about  where  certain 
variables  are  used  throughout  PMS.  For  example,  if  you  wanted  to  know  where 
CNAME  was  used,  you  would  enter  the  variable  name  (or  what  you  remembered  of  it) 
when  you  see  PLEASE  ENTER  THE  VARIABLE  NAME-  you  will  then  be  asked  if 
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Figure  7.40  Submenu  to  detect  data  structure. 

you  want  a  printout.  If  you  do,  ready  vour  printer  first,  then  type  a  capital  Y.  If  not, 
type  N. 

The  information  you  receive  will  list  the  name  of  the  file  or  module  where  it  is 
used,  then  the  type  (file  or  module).  BE  CAREFUL~  If  you  listed  only  a  portion  of 
the  variable  name,  you  may  get  a  list  of  where  all  the  variable  names  are  used. 
However,  by  judiciously  using  this  option  with  OPTIONS  A  and  B,  you  can  have  the 
flexibility  of  discovering  where  variables  are  used  (OPTION  C),  the  exact  variable! field) 
name(OPTION  B),and  how  to  enter  it  into  the  computer  (OPTION  A).  REQUIRED 
INFORMATION— 

The  variable  name  or  at  least  a  few  letters  of  it.  You  may  obtain  this  first 
through  dictionary  option  B  if  you  know  at  least  one  file  in  which  it  is  used. 

Each  portion  of  the  data  dictionary  has  a  menu  to  assist  you  in  entering  the 
required  data  for  your  inquiry.  However,  if  you  find  you  can't  get  out  of  the  dictionary 
for  some  reason,  type  HELP  in  all  capital  letters  when  asked  for  a  variable  name. 
Then  answer  N  to  the  question  about  wanting  a  printout.  This  will  allow  you  to 
return  to  the  main  dictionary  menu  and  then  return  back  to  the  main  PMS  menu 
through  OPTION  D  or  OPTION  X 
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This  allows  you  to  exit  the  dictionary  maun  and  return  to  tte  main  PMS 
mnu.  Before  leaving  the  dictionary,  it  gives  you  soma  farther  information  on  the  files 
that  exist  in  die  dictionary. 

Some  of  the  data  dictionary  files  are  not  accessible  by  you,  and  can  only  be 
accessed  by  someone  having  knowledge  of  DBASE  til  + .  You  can  also  only  read  data 
out  of  die  dictionary:  database  personnel  must  add  new  entries  to  the  dictionary 
through  DBA  'E  III*)'.  The  primary  reason  for  this  is  the  fact  that  most  of  these  files 
contain  information  generally  only  used  by  database  personnel 

Each  of  the  files  is  shown  below  with  a  brief  description  of  what  it  contains: 

•  CONTAINS—  Files  which  contain  elements!  variables) 

•  FILE-  Describes  the  files  in  PMS. 

•  ELEMENT-  The  variable  names  and  information  about  them. 

•  PROCESSES-  The  programs  and  modules  which  process  the  elements  and  .  ■ 
files. 

•  PROGRAMS-  The  programs  which  control  the  operations  of  each  of  the 
menu  options  in  the  PMS  system. 

•  AUTOFILE-  Describes  the  auto  files  in  PMS. 

•  USER-  Describes  the  users  of  PMS. 


vm.  CONCLUSION 


This  than  ha  focused  oa  application  of  a  data  ban  system  for  a  Republic  of 

Kona  military  personnel  management  system.  In  order  to  reduce  expenditures  and 

manpower  for  personnel  management  and  to  increase  the  ability  of  combat  soldiers,  it 

is  eery  important  for  the  Korean  military  to  apply  the  computer  system  for  personnel 

management  Since  we  use  dBASE  III  ♦  for  application  program  in  this  thesis,  we 

should  use  -relational  data  baa  model  Therefore,  we  reviewed  the  basic  knowledge 

about  a  dam  base  system  in  Chapter  II  and  discussed  the  general  concept  of  relational 

model  in  Chapter  III.  After  that  we  focused  precisely  about  the  design  problem  of  the 

relational  model  in  Chapter  IV.  In  Chapter  V,  we  discussed  the  practical  system 

analysis  and  relational  database  design  for  a  Korean  Army  personnel  management 
•  •  •  • 
system.  In  Older  to  maintain  and  use  the  data  base  system  effectively,  we  discussed  the 

relational  implementation  in  Chapter  VI.  Especially,  in  Chapter  VII,  processing 

procedure  to  access  actual  program  in  Appendix  A  eras  shown.  When  we  construct  a 

data  file  to  access  this  program  ere  should  consider  theoretical  problems  that  are 

discusaad  in  Chapter  IV.  In  prototyping  personnel  data  base  in  this  thesis,  all  data 

items  such  as  career,  assignment,  education,  etc  is  based  on  the  Korean  army 

personnel  record.  Because  of  the  military  security  problem  we  use  artificial  sample 

data  for  prototyping. 

In  order  to  strengthen  the  readiness  of  the  Korean  military  under  the  alert  states, 
it  is  imperative  that  personnel  management  be  performed  very  efficiently.  A  most 
important  consideration  in  data  base  development  is  to  store  data  so  that  it  can  be 
used  for  a  wide  variety  of  applications  and  can  be  changed  quickly  and  easily.  In  order 
to  perform  these  functions,  the  data  should  be  independent  and  functionally  dependent 
on  key  values.  It  should  also  be  possible  to  query  the  data  base  to  satisfy  user's 
requirements  using  application  programmer  the  Database  Management  System! DBMS) 
itself.  These  data  items  should  contain  usefUl  information  for  decision  makers  to 
analyze,  plan  and  manage  a  personnel  organization.  However,  a  data  base  is  the 
interface  between  people  and  machines.  Data  base  design  is  a  two-phased  process. 
This  thesis  examined  both  logical  and  physical  data  base  design  process,  and  this 
process  is  an  iterational  process  to  get  closer  to  an  acceptable  and  optimal  design. 
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APPENDIX  A 
PROGRAM  STRUCTURE 


APPENDIX  B 
PROGRAM 


1.  DRTVER.PRG 


*  Module  nano  tDRXVER.PRG 

*  Author  :KXM,  SAM  NAM 

*  Oat*  <31  OCT  86 

*  Purpose  i Thla  la  the  DRIVER  nodule  for  the  entire  system. 

*  It  queries  the  user  for  task  selection  and  calls 

*  the  correct  module  to  service  that  request. 

*  When  control  is  returned  from  the  calling  module 

*  the  user  is  asked  if  more  information  is  required. 

*  If  yes,  then  the  process  is  repeated,  else,  the 

*  program  terminates. 

*  Called  by  <  DRIVER  is  called  at  system  startup 

*  Modules  called  »MENUSCR, TABLE, LISTING, REPORTS, UPDATE, EDIT, DICT 


*  Variables  used 

*  Global  <  i  <  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  •  Local  <  none 

*  Set  up  loop  for  presenting  menu. 


*Close  all  open  files 
CLEAR  ALL 

— — ■ —  Set  working  working  environment 
SET  TALK  OFF 
SET  ESCAPE  OFF 
SET  BELL  OFF 
SET  HEADING  OFF 
SET  HELP  OFF 
SET  MENU  OFF 
SET  SAFETY  OFF 
SET  STATUS  OFF 

Create  underline  variable,  Uline. 
uline-REPLICATE  80) 

— -  Create  memory  variable  for  today's  date. 
today-DATEQ 

A********************************************************************* 


*  This  sets  up  the  CRASH . TXT  file  which  records  all  actions  so 

*  that  if  the  system  crashes,  the  data  base  can  be  recreated.  This 

*  file  is  deleted  if  the  system  terminates  normally. 
**************************&***********************&******************* 


SET  ALTE  TO  CRASH 
SET  ALTE  ON 
DO  WHILE  .T. 

*  DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  DO  FOREVER 

*  The  DO  WHILE  will  be  terminated  by  an  EXIT  command 

*  Clear  the  screen  and  display  the  main  menu 
CLEAR 

DO  MENUS CR 

|  2,11  SAY"  OFFICER  PERSONNEL  MANAGER" 
|  2,62  SAY  "E  N  T" 

|  6.36  SAY  "MENU" 

@  19.33  SAY  "INFORMATION" 

*  8,12  SAY  "A.  PERSONNEL  ALLOTMENT  TABLE." 

|  9.12  SAY  "B.  LISTING." 

9  10,15  SAY  "  Any  query  that  requires  a  listing  or  information" 
§  11,12  SAY  "C.  REPORT (personal  record  card)." 

|  12,12  SAY  "D.  UPDATE.’' 
f  13,12  SAY  "E.  EDIT." 

0  14,12  SAY  "F.  DICTIONARY." 


15.12  SIT  "0.  CHANGE  DAT*." 

16.12  SIT  "X.  EXIT."  _ 

1,9  SIT  "MTS  TIM1" 

_J,55  SIT  "UPDATED  ST" 

21,5  SIT  today 
,  21,19  SIT  TIME() 

*  •  21,55  SIT  mu* 

#  23,10  SIT  ,r[Enter  (election 
DO  WHILE  ,T. 


<  I  -  G,  or  X  to  Exit  )  *  *  ]" 


i-0 

DO  WHILE  i-0 
i-XNKEYQ 

S  21,19  SIT  TIME() 

23,54  SAT  "" 

IP  U^PER  j?CHR( i) ) $ "IBCDEFOX" 

END  IF 
i-0 
ENDDO 

9  23,54  SAT  UPPER(CHR(i)) 

IP  .NOT.  CHR(i)$"Gg" 

EXIT 
ENDIF 

SET  COLOR  TO  N/W 

?  19,33  SAT  "INFORMATION" 

15.12  SAT  "G.  CHANGE  DATE." 

SET  COLOR  TO  W/JJ 
9  21,5  GET  today 
READ 

21,5  SAT  today 
19,33  SAT  "INFORMATION" 

1-15,12  SAT  "G.  CHANGE  DATE." 
i  23,54  SAT  "  " 

ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 

RELEASE  i, today 
SET  TALK  ON 
SET  ESCAPE  ON 
SET  BELL  ON 
SET  HEADING  ON 
SET  HELP  ON 
SET  MENU  ON 
SET  SAFETY  ON 
SET  STATUS  ON 
CLEAR 
RETURN 

•CASE  CHR(i)$"Aa" 

DO  TABLE 
CASE  CHR(i)$"Bb" 

DO  LISTING 
CASE  CHR(i)$"Cc" 

DO  REPORTS 
CASE  CHR(i)$"Dd" 

DO  UPDATE 
CASE  CHR(i)$"Ee" 

DO  EDIT 

CASE  CHRfi)$"Ff" 

DO  DICT 
ENDCASE 
ENDDO 

SET  ALTE  OFF 
CLEAR  ALL 
CLOSE  ALTE 
ERASE  CRASH.TXT 

* - when  done, return  to  main  menu 

RETURN 
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********* 


a.  MENUSCR.PRG 


Hodul* 

Author 

Cat* 

SSI  callad 
Variables  used 


i  MENUSCR.PRG 
i  KIM.  SAM  NAM 
*  30  OCT  86 
t  Menu  screen 
i  None 

t  Local  <  none 

1 >****a*****s***************************** 


today  t  holds  date 

fc* ***** 


**************** 


Set  up  presenting  menu 

****************** 


******************************************* 


1,9  TO  3,69 

4.1  TO  24,77  DOUBLE 
0  6,3  TO  17,75 

5.30  TO  7,46  DOUBLE 

6.31  SAY  SPACE (15) 

1$,3  TO  22,75 

18.30  TO  20,46  DOUBLE 

19.31  SAY  SPACE(15) 

5.2  SAY  REPLICATE (CHR( 176) ,28) 

6.2  SAY  CHR(176 

7.2  SAY  CHR(176 

8.2  SAY  CHRi 176 

9.2  SAY  CHRJ176 

10.2  SAY  CHR(17t 
0  11,2  SAY  CHR(176) 

0  12,2  SAY  CHR(176) 

@  13,2  SAY  CHR( 176) 

0  14,2  SAY  CHR(176) 

S15,2  SAY  CHR( 176) 

16,2  SAY  CHR(176) 
f  17,2  SAY  CHR(176 

18,2  SAY  REPLICATE (CHR( 176), 28) 

,  19,2  SAY  CHR(176) 

|  20,2  SAY  CHR( 176) 

21,2  SAY  CHRi 176 ) 

22,2  SAY  CHR(176)_ 

23,2  SAY  REPLICATE (CHR( 176), 75) 

22,76  SAY  CHR?176) 

21,76  SAY  CHR{176 

20,76  SAY  CHR(176 

19,76  SAY  CHR(1761 
18,47  SAY  REPLICATE(CHR(176) ,30) 
A  17,76  SAY  CHR(176' 

0  16,76  SAY  CHR(176 i 

15,76  SAY  CHR(176 
.  14,76  SAY  CHR(176 

f  13,76  SAY  CHR(176 

12,76  SAY  CHRi 176 j 

11,76  SAY  CHR(176 

10,76  SAY  CHR(176 

9,76  SAY  CHR(176) 

8,76  SAY  CHR(176) 

7,76  SAY  CHR(176) 

6,76  SAY  CHR(176) 

5.47  SAY  REPLICATE (CHR< 176), 30) 

19,33  SAY  "INFORMATION'* 

20,8  SAY  "DATE  TIME" 

20,55  SAY  "UPDATED  BY" 

21,5  SAY  today 
T  21.19  SAY  TIMftO 
*0  2i,52  SAY  gname 
RETURN 


I  TABL&PRG 


*  Nodule 

*  Author 

*  Dot* 


Purpose 


■TABLE. PRO 
tKXM.  SAM  MAN 
ti  MC  86 

(This  is  th«  DRIVER  nodule  for  personnel  allotment. 
Whan  control  is  r« turned  from  the  called  module 
the  user  is  asked  if  more  information  is  required 
and  the  process  is  repeated,  or  control  is  passed 
back  to  the  DRIVER  module. 

_  «  DRIVER 

Nodules  called  : MENUS CR 

*  Variables  used  t 

*  Global  i  i  t  holds  the  value  of  the  user  input. 

*  today i  holds  date 

JLJU 


*  Called  by 

*  Mnrhi  1  •>  ri 


Set  up  allotment  tab! 
********************** 


e. 


.X. 


rrirsp 
DO  WHILE 
CLEAR 
DO  MENUSCR 

9  2,15  SAT  "PERSONNEL  ALLOTMENT 
6.35  SAT  "TABU" 

19,33  SAT  " INFORMATION" 

10.18  SAT  "COMPANY  GRADE  OFFICER «“ 

11.18  SAT  "FIELD  GRADE  OFFICER  i" 
m  12,18  SAT  "GENERAL  GRADE  OFFICER i" 

#  14,18  SAT  "  TOTAL  «« 

16.18  SAT  "****  x.  Return  to  main  menu  ****** 

f  20,8  SAT  "DATE  TIKE" 

20,55  SAT  "UPDATED  BT" 

.  21,5  SAT  today 
9  21.19  SAT  TIME() 

*  9  2f,S5  SAT  gname 

9  23,10  SAT  "  [  Enter  X  to  Exit 

USE  member  INDEX  member 
FIND  varrent  officer 

COUNT  WHILE  ranks  *  "varrent  officer"  TO  ral 
FIND  2nd  lieutenent 
COUNT  WHIU  ranks  - 
FIND  1st  lieutenent 

COUNT  WHIU  ranks  ■  "1st  lieutenent"  TO  xx3 
FIND  captain 
COUNT  WHIU  ranks 
FIND  major 
COUNT  WHIU  ranks 


"2nd  lieutenent"  TO  ra2 


"captain"  TO  ra4 


"major"  TO  ra5 
FIND  lieutenent  colonel 

COUNT  WHIU  ranks  *  "lieutenent  colonel"  TO  ra6 
FIND  colonel 

COUNT  WHIU  ranks  *  "colonel"  TO  ra7 
FIND  brigader  general 

COUNT  WHiU  ranks  *  "brigader  general"  TO  xx8 
FIND  major  general 

COUNT  WHIU  ranks  ■  "  major  general"  TO  xx9 
FIND  lieutenent  general 

COUNT  WHIU  ranks  ■  "lieutenent  general"  TO  ralO 
FIND  general 

COUNT  WHIU  ranks  ■  "general"  TO  rail 
company  ■  ral  +  ra2  +  ra3  +  ra4 
field  *  ra5  ♦  Xx6  +  ra7 
gener  *  raS  +  ra9  +  ralO  +  rail 
addsum  *  company  ♦  field  *  gener 
f  10,45  SAY  company 
f  11,45  SAY  field 
9  12.45  SAT  gener 


1«0 

DO  WCti  1-0 

fflWk  TIHE() 

fy2u^m|&(i)  )$"x" 

f5xr 


ENDDO 


•23,54  SAT  OPPER(CHR(i) ) 
IF  .MOT.  CHR(i)$"  " 

EXIT 
ENDIF 
READ 
ENDDO 
DO  CASK 

CASE  CHR(i)$  "Xx" 

CLEAR 

CLOSE  DATABASES 
RETURN 
ENDCASE 


when  done ,  return  to  Min  aenu 


3.  LISTING.PRG 


Purpose 


*****  ******************************************************************** 

*  Module  nasM  : LISTING. PRG 

*  Author  >PARK,  JAE  BOCK 

*  Date  :1  nov  86 

*  Purpose  >This  is  the  DRIVER  nodule  for  the  listing  system. 

*  It  queries  the  user  for  task  selection  and  calls  the 

*  required  modules . 

*  When  control  is  returned  from  the  called  module, 

*  the  user  is  asked  if  more  information  is  required 

*  and  the  process  is  repeated,  or  control  is  passed 

*  back  to  the  DRIVER  module. 

*  Called  by  «  DRIVER 

*  Modules  called  « MENUS CR,  L_ALL,  L_AS SI ON,  L.EDUCAT,  L.PROMOT 

*  Variables  used  > 

*  Global  i  i  «  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*AAAA**AA.I.A;uSa.I.AAAA?AAAA.I.AAAAAAAAAAAAAAAAAAAAAAAA*AA*A*AAAAAAAA*A*AAA 

*  Set  up  loop  for  presenting  menu. 

*AAA*AAA*A*A**A*5****S***i*Si****i**»**********#A****A**************** 


*  Called  by 


**************** 


********************************* 


CLEAR 

DO  WHILE  .T. 

CLEAR 

DO  MENUS CR 

2,32  SAY  "L  I  S  T  I  N  0  M 
i  >  6.34  SAY  "SUBMENU" 

H  19,33  SAY  "INFORMATION" 
n  8,12  SAY  "A.  List  all  officers." 

i  i  9,12  SAY  "B.  List  all  new  officers  for  assignment." 

ii  10,12  SAY  "C.  List  all  officers  educated.  " 

ii  11,12  SAY  "D.  List  all  officers  for  promotion  test." 
ii  12,12  SAY  "E.  Change  date" 
n  14,12  SAY  "X.  Return  to  main  menu" 

M  20,8  SAY  "DATE  TIME" 

H  20,55  SAY  "UPDATED  BY" 
n  21,5  SAY  today 
21,19  SAY  TIME( ) 

*  •  21,55  SAY  gname 

•  23,10  SAY  "  [  Enter  selection  (  A  -  E,  or  X  to  Exit  )  i 
DO  WHILE  .T. 


TXJB() 

MM  W 

(i»$- 


EXIT 
ENDIF 

SET  COLOR  TO  N/V 

S  19,33  SAT  N INFORMATION" 
12,12  SAT  NE.  CHANGE  DATE" 
SET  COLOR  TO  W/H 
0  21,5  GET  today 
READ 

21,5  SAT  today 
19,33  SAT  "INFORMATION" 
12,12  SAT  HE.  Change  data" 
23,54  SAT  "  " 

ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 

CLEAR 

RETURN 

CASE  CHR(i)SMAa" 

do  l  iix 

CASE  a?R(T)$"Bb" 

DO  LJ&SIGN 
CASE  :%(i)$"Cc" 

DO  L-BDUCAT 


LEDUCAT 
CASE  a®fi)$«Dd" 

DO  L_PROHOT 
ENDCASE 
ENDDO 

* - — — —  when  dona, return  to  aain  Menu 

RETURN 

a.  L.ALL.PRG 


Module  name 
Author 
Data 
Purpose 


»L.ALL.PRO 
iRlM,  SAM  NAM 
>15  DEC  86 

i This  Module  provides  the  listing  service  required 
to  list  all  members. 

LISTING 


none 


Called  by 
Modules  called 
Variables  used 

Global  t  none 

CLEAR 

SET  TALK  OFF 
park  ■  "x" 
park  *  SPACE(l) 

0  15,5  SAT  "Send  data  to  printer  ?  (T/N) M  GET  park 

Read 

select  1 

USE  main  INDEX  MAIN 
SELECT  2 
USE  member 

JOIN  WITH  Main  TO  all  FOR  sns  •  A->an  ; 

FIELDS  ranks , sns , A->name , A->c_type , orgj>ranch ,p_order 
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•  Ilf tif  mtM 
WfttW  I  MW 


:ar:  at  as  tim  f  d. . 

'  r.  JSr&^SVtC%r 

mjmxmusm 


mm *, 


•  -  -  .at.  nti  •  -  - 

rw  out  tko  port— <1 


om 


f  *'° 

ordor~«*STACI?|o  )' 
rank  •  STAGS j 20) 

•  13,5  SAT  "Liot  for  ufcot  porsooaol  ordor(  or  prooo 
^PitAT  "<  o.g . >  M-3S  Wff  )“  (£ZT  ardor 


17,3  SAT  "Liot  for  uhot  rook  (or  orooo  I 
lt,§  SAT  "(o.f  — — >  lot  lioutoMOt)"  OTT  rook 

ardor  ■  ardor  ♦  rank 
ardor  ■  iowor(ordor) 


to  *mt)m 


TO  TN.aruitor 
“  'Soaa 


to  pr tutor  ’(I/*) 
prlator  oocro. 


•  a rr  m  pier  ” 
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■UTii  t|«  LIST  IP#  aodnls  for  tbo  Hating  ays  ton. 
Tkia  nodule  la  iim  whan  the  uaar  raquiraa  the  list 
of  gfflcera  educated  in  a  particular  couraaa. 


t  LXStlM 


ai^il 

MtMM 


t 

i  nnaae  *  halda  tha  value  of  tha  uaar  input, 
aocaptahla  values  «  ailitary  education 


couraa  nano. 


§  •  " 

Find  ant  ahat 


to  lint. 


fUjw 

s>t 

rrr,’^  Eiat'far  ahat  couraa  nana(  or  proas  RITUM; 

ftfl  nar  -(  a.g  ~>mnwnr  o.a.ckm  )-  art  mho 


couraa 


m  m  m 


iTSU* 

I  -  "  TO  HI.  aria  tar 

.IS  Shf  "Sand  to  printer  MT/W).  "ORTH  PICT  "!" 


Sat  up  printer  nacre. 
HW  ■  T 

Printer  •  "TO  PtUfT" 


gfiy, 

a Sr 

u  .wan  _ 

fS;i  & 


POM  r.educat  POP 

() 


Sprinter 


or  to  nr  sow. 


124 


?  __ 

JUT 


VI 


.....  .  .  return  to  listing  nsnu. 

V.PtOMOT.PIC 


Author 

Onto 

Purpose 


tL  PROKOT.FRG 
tPlRK  JAE  BOCK 
>1  DKC  86 

sThis  is  the  LISTING  module  for  the  listing  system. 
This  nodule  is  used  when  the  user  requires  the 
officers  list  for  promotion  test. 


Celled  by  *  LISTING 
Nodules  celled  t 
Variables  used  » 

Local  t  ranks  holds  the  value  of  the  user  input, 
acceptable  values :  military  rank, 
years  holds  the  value  of  the  user  input, 
acceptable  values s  promotion  year. 

*  _  Global  s  today  s  holds  the  date 

eeeSMHHHWHM*M4r«**M*ft*K*ifc***x**A**********:kA******A**Aifc************** 

r _ ,  menu. 

CLXAK  . 

USI  all  INDEX  r_all 
rank  *  "x" 

Bars  ■Mx" 

MULE  rank  #  '•  "  .OR.  years  *  "  11 

Find  out  rank  and  promotion  year. 

•  2,1  SAT  "LIST  ALL  OFFICERS  FOR  PROMOTION  TEST." 

•  2,60  SAT  today 
•  2,70  SAT  TIKEt) 

•  3,0  SAT  QLINS 

? 

»5,0  rtnaa 

...........  o«t  proposed  and  rank. 

rank  -  SPACE(20) 
lars  •  SPACE(2) 

15,5  SAT  "List  for  what  rank  (or  press  RETURN  to  exit)" 

16,5  SAT  "(e.g  — — >  1st  lieutenant)"  GET  rank 

[AO 

17,5  SAT  "What  is  a  promotion  year?(or  press  RETURN  to  exit)" 

18,5  SAT  "(e.g  - - >  82)"  GET  years 

rank  ■  LOWER (rank) 
years  ■  LONER (years) 

SEEK  rank 
00  CASE 

CASE  rank  *  "  "  .OR.  years  *  "  " 

CLEAR 

CASS  FOUND 0 
•  5,0  gtraa 

ITORE  "  "  TO  TN, printer 
‘  15,15  SAT  "Send  to  printer  ?(T/N). 


STORl 

Lil 


GET  TN  PICT  "I1 


Set  up  printer  macro. 
IF  TN  ■  "T" 

Printer  ■  "TO  PRINT" 

SMDIF 

REPORT  FORM  r jpromote  FOR; 
ranks  *  rank  .AND.  SUBr 
WAIT 

CASE  .NOT.  FOUND () 
rreap 


STR(p_order,l,2)  <*  years  printer 


25 


II 


gNDOO 


f  17,5  85?  N  There  Is  no  "  ♦  rank 
f  MpMSS  ANY  KEY  TO  TRY  MAIN. 

WklT  *  ^ 


Whan  dona,  r  a  turn  to  Hating  menu. 


RETURN 
4.  REPORTS.PRG 


*  Module  name 

*  Author 

*  Data 

*  Purpose 

a 

*  Called  by 

*  Modules  called 

*  Variables  used 

* 

* 

********** 


{REPORTS .PRO 
i PARK,  JAE  BOCK 
tl  DEC  86 

tThis  is  the  DRIVER  module  for  the  report  system. 
This  module  is  used  when  the  user  requires  the 
personnel  record  card. 

*  DRIVER 
s  none 
> 


Global  >  today t  holds  date 
:li2£*^**£*****A*********A**A******************* 


************** 


**************** 
fT.BaP 

USE  all  INDEX  all 
msn 


Set  up  loop  for  presenting  menu. 
*********************************************************** 


DO  WHILE 

*..... 


msn  #  "  " 

------  Find  out  service  number. 

CLEAR 

2,1  SAY  "PERSONNEL  RECORD  CARD." 

2,60  SAY  today 
2,70  SAY  TIME() 

3,0  SAY  ULINE 


service  number. 


0  5,0  CLEAR 

*—————  Get  proposed 
msn  ■  SPACE (8) 

815,5  SAY  "List  for  what  service  number  (or  press  RETURN  to  exit)" 

16,5  SAY  "(e.g  - >  21554)  »  GET  msn 

READ 

msn  *  LOWER(msn) 

SEEK  msn 
DO  CASE 

CASE  msn  *  «  " 

CLEAR 

CASE  FOUND 0 
950  CLEAR 

ACCEPT  "Send  to  printer  ?(Y/N)."  TO  printer 
*......  set  up  printer  . 

IF  printer  *  "Y" 

SET  PRINT  ON 
END  IF 
CLEAR 

REPORT  FORM  rreport  FOR  sns  ■  msn 
WAIT  "  " 

USE  EXPERT 

8  24,5  SAY  "EXPERT  TITLE  " 

LIST  expertitle  FOR  sn«rasn 
WAIT  " 

USE  careers  INDEX  careers 
SEEK  msn 

REPORT  FORM  r  career  FOR  sn*msn 
USE  d eval  INffEX  p.eval 
SEEK  msn 


(MM  rjml  rot 


PROMOTION 

DATE 


PROMOTION" 
ORDBX  " 


np^j^t^^lot  p.»r^M**‘>»,ordir  nilM  Wnak*,) 

_  p.order  TO  p_t 

CLEAR 

•  5,5  SAT  "MUR 

•  1,5  SAY  " 

LIST  FOR  itms n 
CLOSK  OATASASIS 
WAIT  "  '• 

S1LKCT  3 

USE  avardpun 
SELECT  4 

USE  id  an  INDEX  a  Dan 

JOIN  Sira  awardpun  “TO  temp  FOR  p_order«C->p_order  FIELDS  C->kind, ; 

p_ordar , C->  tdata , an 
USE  tanp 

INDEX  (HI  p.order  TO  p.temp 

nri^p 

S5,5  SAT  "  KIND  OF  AWARD  PERSONNEL  ORDER  DATE" 

S,S  SAT  "  AND  PUNISHMENT  .  " 

LIST  FOR  limun 
WAIT  "  " 

CASE  .NOT.  FOUND() 

CLEAR 

S17,5  SAT  "  Thare  is  no  11  +  nan 

24,5  SAT  "PRESS  ANY  KEY  TO  TRY  AGAIN _ 11 

?  cram 

WAIT  '*  <' 

END CASE 

ENDDO 

* — - — -  When  done,  return  to  listing  menu. 

RETURN 


UPDATE.PRG 


Author 

Date 

Purpose 


********************************************************************* 

*  Nodule  name  < UPDATE.PRG 

«KIM,  SAM  NAM 
<27  oct  86 

<This  is  the  DRIVER  module  for  the  update  function. 

It  sets  up  the  main  update  menu,  accepts  input 
from  the  user  and  calls  the  required  modules. 

When  control  is  returned  from  the  called  module, 
the  user  is  asked  if  more  information  is  required 
and  the  process  is  repeated,  or  control  is  passed 
back  to  the  DRIVER  module. 

<  DRIVER 

a MENUS CR,  UPMAIN,  UPEXPERT,  UPEDUCAT,  UPPROMOT, 
UP_AW_PU,  MAINTAIN,  UPEVAL,  UP CAREER 

< 

<  i  <  holds  the  value  of  the  user  input, 
today <  holds  date 

3$S*£*******$*********************************************** 

a***a******SS**)K***SSa*S**Ra2****£*9****** *************************** 

CLEAR 

DO  WHILE  .T. 

CLEAR 

DO  MENUS CR 

•  2,14  SAT  "UPDATE  PERSONNEL  RECORDS" 


* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

********** 
* 


Called  by 
Modules  called 

Variables  used 
Global 
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effort  aaiten 

■UiUtyiMi 


itiM* 


newt  prfMtln  Makers" 
award  iadpunisfeaNAt  r •cords' 
rfonaanca  •valuation11 

>t  records" 

—  _  te" 

Saturn  to  sain  aenu" 

"DATE  TUB" 

S  iif  *WDkTID  IT" 

.  _  SAT  today 

2A%V2i! 

f  21' iS  " [Enter  selection  (A  -  Z,  or  X  to  return  to  Min" 
#23,57  SAT  "  aanu)  i  «  J" 


ws:  - 

DO  MOLE  i*0 

i"|ia|  iiT  tineo 
f  Su>  sat  mm 
If  trfi«i(Qp(i))<" 


a 


IF 


EXIT 


ABCMFOZX" 


SXXT 
SNDXF 

n  COLOR  TO  N/N 
If. 33  SAT  " INFORHATION" 

13.42  SAT  "I.  CHANGE  DATE" 

T  COLOR  TO  N/N 
Jl.S  GIT  today 

21,5  SAT  today _ 

If, 33  SAT  "INFORMATION" 

13.42  SAT  "I.  Chang*  data" 

23,45  SAT  "  " 

SNDDO 
DO  CASK 

CUI  CHR(i)$  "Xa" 
etr»ia 

DO  Maintain 

RETURN 

CASE  Q^(i)»"AaH 
CAM  aSujryb" 

CASE 

00  UFIpUCAT 
CASE  «g)$"Dd" 

CAM  CHRa)f"Ee" 

DO  ufJiLfu 

CASE  <MjUri"Ff" 

“AW 

ENDCAJE 

SNDDO 

* -  when  dona, return  to  nain  n«nu 
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»  »  »  *  * 


i  MAIHTAlKJtG 


Sir 

rVtfOM 


laxmn.iM 
«l5T  SAH  MM 
il  MC  M 

■This  is  tbs  data  file 
updating  and  editing. 
«  UPDATi;  IOXT 


maintenance ,  uaad  for 


OSS  kla 
OKLSTS  ALL 
PACK 

USE  promote  INDEX  pronot 
i  •  an 

field  *  p_order 
DO  WHILE  .not.  IOP<) 

y  -  kald 
1  *  sn 

fialdd  -  p.ordar 
IF  i  «  X 

string  •  SUBSTRf fialdd, 1.2) 
field*  -  SUBSTRiy, 1 ,2) 

IF  string  >  fialds 
fiala  ■  p_ordar 
KMDIP 
EMDir 
IP  i  <>  x 
USB  kirn 
APPEND  BLANK 
REPLACE  sns  WITH  x 
REPLACE  pordar  WITH  y 
USE  promote  INDEX  pronot 
fiald  -fialdd 
ENDIF 

LOCATE  FOR  an  -  i  .AND.  p.order 
SKIP 


fialdd 


USE  kin 

APPEND  BLANK 

REPLACE  sns  WITH  i 

REPLACE  pordar  WITH  fiald 

SELECT  1 

USE  kin 

SELECT  2 

USE  rank  INDEX  rank 

JOIN  WITH  kirn  TO  member  FOR  p  order  -  A->porder  ; 

FIELDS  A->sns, p_order, ranks ,tdate 
err wrr  i 

USE  main  INDEX  MAIN 
SELECT  4 

USE  aeaber 

JOIN  WITH  aain  TO  all  FOR  sns  -  C->sn  ; 

FIELDS  ranks, sns, C->na»a.C->c-typa,orgJbranch, p_order, ; 
tdata , C->born_date , C->born  Dlaca 
USE  all 
RE INDEX 

CLOSE  DATABASES 

Pm.X.N.PRG 


Module  name  tUPMAIN.PRG 
Author  tPARK,  JAE  BOCK 

Data  <22  NOV  86 

Purpose  sthis  is  the  UPDATE  nodule  for  updating  new  member 

It  sets  up  the  add  new  officer  members  menu, 


accepts  input  fron  ths  ussr  and  calls  ths 
required  modules.  When  control  is  returned 
fro*  the  called  nodule,  the  user  is  asked  if  aore 
information  is  required  and  the  process  is  repeated, 
or  control  is  passed  back  to  the  UPDATE  nodule. 

Called  by  «  UPDATE 
Modules  called  iSCREENl 
Variables  used  < 

Global  i  i  t  holds  the  value  of  the  user  input, 
today i  holds  date 

kAAAAAAAAli&SA^AA^ASAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


*  Set  up  loop  for  adding  new 

AAAAAAAAAAAAAAAAxAAAAAAAAAAAAAAAXAAAAi 

USE  aain  Index  main 
sns  ■  "xM 

DO  WHILE  sns  *  "  « 
rT.mp 

!2 , 1  SAT  "Add  new  officer  members" 
2,60  SAT  today 
2,70  SAT  TIME!) 

3,0  SAT  ULINE 


>  for  adding  new  officer  members. 


*— — ----- —  Get  proposed  service  number, 
sns  ■  SPACE (8) 

.9  15, S  SAT  "Enter  service  number  (  or  press  RETURN; 
to  exit)"  GET  sns 
READ 

—  Check  to  see  if  service  number  already  exists, 
sns  *  LOWER (sns) 

SEEK  sns 
DO  CASE 

* - - —  if  u*er  did  not  enter  a  service  number, 

-  clear  the  screen  and  return  to  UPDATE  menu. 

CASE  sns  ■  "  " 

CLEAR 

If  service  number  already  exists, 
notify  user  and  allow  another  try. 

CASE  FOUND () 

9  20,10  SAT  sns  +  "already  exists" 

?  CHR(7) 

WAIT 

* — - —  if  service  number  not  already  taken, 

* — ----  i«t  user  add  it. 

CASE  .NOT.  FOUND O 
APPEND  BLANK 
REPLACE  sn  WITH  sns 
SET  FORMAT  TO  screenl 
READ 

SET  FORMAT  TO 
ENDCASE 

ENDDO(While  user  does  not  enter  blank  for  service  number.) 

REINDEX 

Return  to  UPDATE  menu. 

RETURN 

c.  UPEXPERT.PRG 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 


*  Module 

*  Author 

*  Date 

*  Purpose 

A 

A 

A 

A 

A 


(UPEXPERT.PRG 
(PARK,  JAE  BOCK 
>22  NOV  86 

(This  is  the  UPDATE  module  for  adding  expert  to  the  EXPERT 
database  file.  It  sets  up  the  add  expert  members  menu, 
accepts  inpjt  from  the  user  and  calls  the 
required  modules.  When  control  is  returned 
from  the  called  module,  the  user  is  asked  if  more 
information  is  required  and  the  process  is  repeated, 
or  control  is  passed  back  to  the  UPDATE  module. 


if  t  groin 
called  tnoM 
a  used  t 

Global  i  1  i  holds  the  value  of  the  user  input, 
today t  holds  date 


*************************************** 

*?*S%**?^£^*S&************************* 


ens  *  "x" 

DO  WHILE  sns  t  11  11 
CLEAR 

!2,1  SAY  "Add  expert  members" 
2,60  SAY  today 
2,70  SAY  TIME!) 

3,0  SAY  ULXNS 


Get  proposed  service  number, 
sns  a  SPACE (8) 

9  15,5  SAY  "Enter  service  number  (  or  press  RETURN; 

to  exit)"  GET  sns 

READ 

check  to  see  if  service  number  already  exists. 

USE  main  INDEX  main 
sns  *  LOWER(sns) 

SEEK  sns 
DO  CASE 

If  user  did  not  enter  a  service  number, 

— — -  clear  the  screen  and  return  to  UPDATE  menu. 

CASE  sns  «  "  " 

CLEAR 

*  - If  service  number  does  not  exist, 

* — — —  notify  user  and  allow  another  try. 

CASE  .NOT.  FOUND() 

9  20,10  SAY  sns  *  "does  not  exist" 

?  CHR(7) 

WAIT  „ 

*—.....  if  service  number  already  exists  in  the  MAIN  file. 
*.......  check  to  see  if  service  number  and  expert  title  already 

*  . exists  in  the  EXPERT  file. 

CASE  FOUND () 

USE  expert  INDEX  expert 

*- - - - -  Set  up  loop  for  adding  expert  titles. 

ttitle  »  «X" 

DO  WHILE  ttitle  #  "  " 

CLEAR 

9  2,1  SAY  "Add  expert  members" 

9  2,60  SAY  today 

t2,70  SAY  TIME!) 

3,0  SAY  ULINE 

? 

7 

* — .........  Qst  proposed  expert  title 

ttitle  ■  SPACE (20) 

9  15,5  SAY  "Enter  expert  title  (or  press  RETURN  to; 
exit)"  GET  ttitle 
READ 

*—  Check  to  see  if  service  number  already  exists. 

SEEK  sns 
DO  CASE 

*. — ....  if  user  <3^^  not  enter  a  expert  title, 

*... -  clear  the  screen  and  return  to  previous 

* — .. —  program. 

CASE  ttitle  a  «  " 

CLEAR 

*— — —  If  service  number  does  not  exists, 

*...—._  add  a  expert  title.  . 

CASE  .NOT.  FOUND () 


imm>  BLANK 
REPLACE  OMi 


REPLACE  exper title  WITH  ttitle 
KEPLACS  in  WITH  ins 

* - If  ssrvics  number  already  Mists  in  ths 

s — — —  EXPERT  fils,  check  to  see  if  expert 

*— - title  already  exists  in  the  EXPERT  file. 

CASE  FOUND () 

USE  expert  INDEX  expertitls 
t title  ■  LOWER ( t title ) 

SEEK  ttitle 


DO  CASE 

CASE  FOUND 0 

9  20,10  SAT  ttitle  +  "already  exists" 

?  CHR(7) 

WAIT 

*— .. ...  if  expert  title  not  already  taken, 

*- - let  user  add  it. 

CASE  .NOT.  FOUND() 

APPEND  BLANK 

REPLACE  expertitlc  WITH  ttitle 
REPLACE  sn  WITH  sns 
ENDCASE 
ENDCASE 

ENDDO(While  user  does  not  enter  blank  for  expert  title) 
ENDCASE 
REINDEX 
CLEAR 

ENDDO (While  user  does  not  enter  blank  for  service  number) 

*- — — ------  Return  to  UPDATE  menu. 

RKTd.  UPEDUCAT.PRG 
*  Module  name  s UPEDUCAT.PRG 


*  Author  *KIM,  SAM  NAM 

*  Date  *31  NOV  86 

*  Purpose  tThis  is  the  UPDATE  module  for  adding  education  results. 

*  It  quries  the  user  for  task  selection  and  calls 

*  the  correct  module  to  service  that  reguest. 

*  When  control  is  returned  from  the  calling  module, 

*  the  user  is  asked  if  more  information  is  required 

*  If  yes,  then  the  process  is  repeated,  else,  the 

*  program  terminates . 

*  Called  by  * UPDATE 

*  Modules  called  *MENUSCR,  UP_MED1 ,  UP  M  ED2 

*  Variables  used  * 

*  Global  *  i  *  holds  the  value  of  the  user  input. 

*  today*  holds  date 

*  _  Local  *  none 

********************************************************************** 

****************£****§*****§********£********************************* 

CLEAR 

DO  WHILE  .T. 

*  DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  DO  FOREVER 

*  The  DO  WHILE  will  be  terminated  by  an  EXIT  command 

*  Clear  the  screan  and  display  the  main  menu 
DO  MENUS CR 

9  2,11  SAT  "ADD  MILITART  EDCATION  RESU; 
LTS" 

iS ,36  SAT  "SUBMENU" 

19,33  SAT  "INFORMATION" 

10,21  SAT  "A.  Add  military  education  results" 

11,21  SAT  "B.  Add  personal  education  results" 


11.21  SAT  "B.  Add  personal  e 

12.21  SAT  "C.  Change  date" 

13.21  SAY  "X.  Exit* 

20,8  SAT  "DATE  TIME" 

20,55  SAY  "UPDATED  BY" 

21,5  SAT  today 


education  results" 
education  results" 


•  21.19  SAT  THS() 

?2340*slf  ',gf*Ent«r  ••lection  (  A  -  C,  or  X  to  Exit  ).  i 

t5)  ’ 


*21,19  SAT  TIME() 

23,54  SAT  «" 

IF  UPPER(CHR(i) )S"ABCX" 
EXIT 

END  IF 
i*0 
ENDDO 

•  23,54  SAT  UPPER (CHR(i)) 

IF  .MOT.  CHR(i)$"Cc" 

EXIT 
END  IF 

SET  COLOR  TO  N/W 

?  19,33  SAY  "INFORMATION" 
12,21  SAY  "C.  CHANGE  DATE" 
SET  COLOR  TO  W/N 
•  21,5  GET  today 
READ 

!21,5  SAY  today 

19,33  SAY  "INFORMATION" 
12,21  SAY  "C.  Change  date" 
23,54  SAY  "  « 

ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 

CLEAR 

RETURN 

CASE  CHR{i)$',Aa" 

DO  UP  k  EDI 
CASE  CHjT(f)$"Bb" 

DO  UP_M_ED2 


ENDCASE 

ENDDO 

*  - -  when  done, return  to  main  menu 

RETURN 

/.  UP_M_ED1.PRG 

********************************************************************** 

*  Module  name  :UP _ML.ED1.PRG 

*  Author  .-PARK,  JAE  BOCK 

*  Date  *22  NOV  86 

*  Purpose  iThis  is  the  UPEDCAT  module  for  adding  education  results. 

*  It  sets  up  the  add  military  education  result,  accepts 

*  input  from  the  user  and  calls  the  required  modules. 

*  When  control  is  returned  from  the  called  module,  the 

*  user  is  asked  if  more  information  is  required  and  the 

*  the  process  is  repeated,  or  control  is  passed  back  to 

*  the  UPEDUCAT  module. 

*  Called  by  *  UPEDUCAT 

*  Modules  called  *SCREEN3 


*  Purpose 


*  Called  by  * 

*  Modules  called  *2 

*  Variables  used  * 

*  Global  * 


*  Global  *  i  *  holds  the  value  of  the  user  input. 

*  today*  holds  date 

*  Local  *  none 

********************************************************************** 

*  Set  up  loop  for  adding  new  officer  members. 
********************************************************************** 

USE  m_educat  Index  m_educat 
name*  "x" 

DO  WHILE  name  #  "  " 

CLEAR 

S2,l  SAY  "Add  military  education  results" 

2,60  SAY  today 


f  i:r JFJBU 

A....—. flat 


8*B,5  Sr^inter  court#  mm  (  or 
to  exit)"  QIT  MM 

KKAD 

Chock  to  ooo  if  court# 
MM  *  LOWER  (Mute) 


dot  propottd  court#  mm. 

20)  _ 

lnt#r  court#  mm  (  or  pr#tt  RETURN* 


*- - Chock  to  #••  if  court#  mm  already  exists. 

mm  *  LONER  (mm) 

SEEK  MM 
DO  CASE 

xf  ut#r  did  not  «nter  t  court#  mum, 

cl##r  th#  tcr##n  and  return  to  UPEDUCAT  t#nu. 

CASE  mm  *  "  •• 
cr^a# 

a.......  jf  court#  name  already  exiata, 

a.......  notify  ua«r  and  allow  another  try. 

CASE  FOUNDO 

9  20,10  SA?  name  ♦  "already  exiata" 

?  CHR(7) 

WAIT 

— ---  If  courte  name  not  already  taken, 
a.......  xet  uter  add  it. 

CASE  .NOT.  FOUND Q 
APPEND  BLANK 
REPLACE  cname  WITH  name 
SET  FORMAT  TO  screen3 
READ 

SET  FORMAT  TO 
ENDCASE 

ENDDO(While  user  does  not  enter  blank  for  service  number.) 

RE  INDEX 

a - .......  Return  to  UPDATE  menu. 

RETURN 

2.  UP_MJED2.PRG 

AA*A******AAAAAAAAAAAA*A****A****A*AA*AAAAAAAAAAAAAAAAAAA**AAAAAAAA** 

*  Module  name  «UP  M  ED2.PRG 

*  Author  iPAKK,  JAE  BOCK 

*  Date  s22  NOV  86 

*  Purpose  iThis  it  the  UPEDUCAT  module  for  updating  military 

*  education  ph«ii1  tn  the 


*  Called  by 


iThia  it  the  UPEDUCAT  module  for  updating  military 
education  results  to  the  EDUCATMn  file. 

It  sets  up  the  add  military  education  results, 
accepts  input  from  the  user  and  calls  the 
required  modules.  When  control  is  returned 
from  the  called  module,  the  uter  it  asked  if  more 
information  is  required  and  the  process  is  repeated, 
or  control  is  passed  back  to  the  UPEDUCAT  module. 

» UPEDUCAT 


*  Modules  called  :SCREEN2 

*  Variables  used  t 

*  Global  t  i  <  holds  the  value  of  the  user  input. 

*  today i  holds  date 

*  Local  *  none 

aaaaaaaaaaaaaaaaaaaaaaa*a*aa*aaaaa**a*a*aaaaa*a*a*aaaaaaaaa*aaaaaa**aa 

*  . Set, up. loop  for  adding  military  education  results. 

aaaaaaaaaaaaaaaaaaaaaaaa*aa***aaaa****a**aaaaaaa****aaaa***aaaaaaaaaa* 

USE  educatmn  INDEX  educatmn 
name  ■  "x" 
snt  ■  "x" 

DO  WHILE  tns  #  "  "  .OR.  name  #  "  « 
a..........  Find  out  what  service  number  to  add. 

CLEAR 

?2,1  SAY  "ADD  PERSONAL  EDUCATION  RESULTS" 

2,60  SAY  today 

S2,70  SAY  TIMED 
3,0  SAY  ULINE 


? 

? 

A. 


- — ... . —  Gat  proposed  servlet  number  and  class  mbs. 

■  *?ACI(20) 

... .  SPACEtl) 

#15,5  $17  "Add  for  what  service  number 
M  GST  sns 

mo 

<  17,5  SAY  "Add  for  whet  class  name" 

#  18,7  SAT  "(  or  press  RETURN  to  exit)"  GET  name 
READ 

—  Try  to  find  that  service  number, 
sns  *  LONER (sns) 

SEEK  sns 
00  CASE 

* — — —  If  no  service  number  entered,  return  to  UPDATE  menu. 

CASE  sns  *  11  11 

CLEAR 

CASE  name  *  11  " 

CLEAR 

* — .. — if  service  number  found,  try  to  find  that  class  name 
* — - —  an<j  add  using  screen2  format. 

CASE  .NOT.  FOUND (} 

USE  education  INDEX  ccname 
snss  *  sns  +  name 
snss  *  lover (sns) 

SEEK  snss 
IF  .NOT.  F0UNDO 
USE  educatmn 
APPEND  BLANK 
REPLACE  sn  WITH  sns 
REPLACE  cname  WITH  name 
SET  FORMAT  TO  screen2 
READ 

SET  FORMAT  TO 
ELSE 

@  5,0  CLEAR 

9  15,5  SAY  name  +  "  already  exists" 

?  CHR(7)  1 

WAIT 
ENDIF 

*--- -  Otherwise, warn  user  and  allow  another  try 

CASE  F0UND() 

@17,5  SAY  "there  is  no  "  +  sns 
@  24,5  SAY  "Press  any  key  to  try  again..." 

WAIT  "  " 

ENDCASE 

ENDD0( Continue  editing  until  user  requests  exit) 

*  - Return  to  UPEDCAT  menu. 

RETURN 

e.  UPPROMOT.PRG 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 

*  Module  name  : UPPROMOT.PRG 

*  Author  iPARK,  JAE  BOCK 

*  Date  :22  NOV  86 

*  Purpose  :This  is  the  UPDATE  module  for  adding  recent 

*  promotion  members  to  the  PROMOTE  database  file. 

2  It  sets  up  the  add  recent  promotion  members  menu, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,  the  user  is  asked  if  more 

2  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UPDATE  module. 

*  Called  by  : UPDATE 

*  Modules  called  :MENUSCR,  UPPF.0M01,  UPPR0M02 

*  Variables  used  j 

*  •  Global  »  i  i  holds  the  value  of  the  user  input. 

*  today «  holds  date 
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’■jUik*. 


MUI.  DO  WHiyt  TRUEi.e,  DO  FOREVER 


rr.9\9 

DO  WHILE  .7. 

*  DO  WHILE  .7. _ _  _ _ 

*  Th«  DO  WHILE  will  be  terminated  by  an  EXIT  co— and 

*  Claar  tha  scraan  and  dlaplay  tha  main  menu 
DO  MENUS CR 

‘  2,13  SAT  "ADD  RECENT  PROMOTION  RE 
6,36  SAT  "SUBMENU" 

19,33  SAT  "INFORMATION" 

10.21  SAT  "A.  Add  promotion  orders" 

11.21  SAT  "B.  Add  personal  promotion  records" 

12.21  SAT  "C.  Change  date" 

13.21  SAT  "X.  Exit" 

20,8  SAT  "DATS  TIME" 

20,55  SAT  "UPDATED  BT" 

21,5  SAT  today 


CORDS" 


9  21.19  SAT  TIMEO 
*@21,52  SAT  gname 


@  23,10  SAT  "  [  Enter  selection  (  A  -  C,  or  X  to  Exit  ) 
DO  WHILE  .T. 
i»0 

DO  WHILE  i»0 
i»INKET() 

S  21,19  SAT  TIMEO 
23,54  SAT  »» 

IF  UPPER(CHR(i))$?1ABCX" 

EXIT 

ENDIF 

i*0 

ENDDO 

@  23,54  SAT  UPPER (CHR(i) ) 

IF  .NOT.  CHR(i)$"Cc" 

EXIT 

ENDIF 

SET  COLOR  TO  N/W 
9  19,33  SAT  "INFORMATION" 

9  12,21  SAT  "C.  CHANGE  DATE" 

SET  COLOR  TO  W/N 
9  21,5  GET  today 
READ 

9  21,5  SAT  today 
9  19,33  SAT  "INFORMATION" 

9  12,21  SAT  "C.  Change  date" 

9  23,54  SAT  "  " 

ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 

CLEAR 

RETURN 

CASE  CHR(i)$"Aa" 

DO  UPPROMOl 
CASE  CHR(i)$"Bb" 

DO  UPPR0M02 
ENDCASE 
ENDDO 

* - - - when  dona, return  to  main  Menu 

RETURN 

/.  UPPROMOl.PRG 


1" 


********************************************************************* 

*  Module  name  : UPPROMOl.PRG 

jPARK,  JAE  BOCK 
:22  NOV  36 

tThis  is  the  UPPROMT  nodule  for  adding  promotion  orders 
to  tha  RANK  file.  It  sets  up  tha  add  promotion  oders. 


*  Author 

*  Date 

*  Purpose 
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'  UST^xSV. 


of  the 


«  rani 

order  ■  __ 

«U  or*r  •  -  - 
— II 

,1  UT  -Add 
to  SAY  today 

70  sar  rami) 

0  SAY  BLIM 


Oat 
STACK  20) 
SAX  "la tar  pi 
ait)-  OK  order 


ordara.1 


* - Chock  to  aaa  if  pi 

ordar  *  LOMU  (ordar) 


tioa  ordar  (  or  proaa 

tioa  ordar  alroody  oaiata. 


00  <£SI 


If  usor  did  not  oator  a 
cioor 


_  the 

CASS  order  *  "  " 


re 


Itlai  ■ 

to  QFfWDI 


pronotion  order  already  exists, 
notify  user  and  allow  another  try. 


m, 


If  prenotion  order  al 
y  user  and  allot 

SAY  order  ♦  -already  exists" 


NAZI 

* — .... .  jf  pronotion  ordar  not  already  taken , 

--------  let  user  add  it. 

CASt  .WOT.  FPOMPQ 

ATUMD  BLANK 

UTLAClp  order  WITH  order 
SIT  FORMAT  TO  screens 

ASAO _ 

StT  FORMAT  TO 


DOO(WI 

IMDCZ 


SS2“« 


user  does  not  enter  blank  for  pn 
Return  to  OFPAOMOT 
2.  UPPR0M02.PKG 


tioa  order) 


*  Module  t 

*  Author 

*  Oats 

*  Purpose 

* 

* 

* 

* 

* 


i  UF  PROMO  2  .MW 


true,  JAS  BOCK 
.22  W6v  M 

•This  is  the  OYPROMOT  nodule  for  adding  personal 
pronotion  recorda  to  the  PROMOTE  file, 
it  sets  up  the  add  personal  pronotion  record, 

Ets  input  fron  the  user  end  calls  the 
red  nodules.  When  control  is  returned 
the  called  nodule.  the  user  is  asked  if  nora 
nation  is  required  and  the  process  is  repeated 
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rtf.  •  ■  - 

•mmmm.  Chock  to  M 

M«  urnm(mm) 

ft*  „ _ 


oorvico 


»r  <  or 


if  service 


aSTVW  to  exit)"  OR  sns 


r  (lrttdf  exists. 


r#  nagf  44i  not  an  tor  i  strriet 
—  clear  tte  •croon  and  roturn  to  OPDATI  oonu. 


at-* 

“ —  u 


*— ■ — • —  If  service  nabor  do 

— -  — Uil  #*r  all* 

“fiF— 

mrr 


r  do**  not  exist, 
kllow  matter  try. 


not  osiot* 


service  mater  already  oaioto, 
t  aoor  odd  it. 


"—----lot  aoor  mo  it. 

CMSPNMK)  _ 

mm  arosoto  mn  areawte 

*------ ----  lot  us  loop 

■—•————  record. 


for  adding  porsonol  promotion 


fcdori  ■  "x" 

00  ardors  t  *  * 


rsenel  proaotion  records . 1 


oslt)1 


ILfiS.?* 

2.70  SAT  Tllflf ) 
3,0  SAT  OLXW 


7 

*—————  mt  proposed  proaotion  order. 

rdoro  ■  »AC«(20T  r  _ 

15, S  SAT  "Inter  proaotion  ordor  (or  prooo  RSTUSN  to; 

•  IS, 10  SAT  "(o.g  -—>86-100  AIMT)M  0ST  ordor* 

*--  Ctecfc  to  soo  if  oorvico  nuater  olroody  exists. 

sent  oao 

DO  CASS 

*—— —  If  user  did  not  on  tor  o  proaotion  ordor, 
eloor  tte  ocroon  ond  roturn  to  previous 
proarm. 

CASS  orders  *  "  11 
rrxoo 

* - If  oorvico  nuabor  does  not  exists, 

add  o  porsonol  promt  ion  rocord  to  PtOHOTK 


131 


“Vftj 

B 


K) 


_ «*" 

*  - Ifff 

*  - Stir* 


a. 


ady  exists  In  tha 
to  see  if  coursj^ 


ts  in  the  IDUCATMN 


NHZLI  an*" ana" 
_order  TO  tenp 


corr  to  u 

UMtanp. 

Mil’s, ordar  TO  tea 
OM  tenp  flba  tw 
orders*  LONIR(orders) 

SISK  ordara 
00  CASI  _ _ 

casi  foundo 

? 

NUT 

a.......  if  promotion  ordar  not  already  takan, 

a.......  itt  user  add  it. 

CASI  .NOT.  FOUNDO 
USIpronote  XMDKX 
imlb  BLANK 

SSfLACB  p.ordar  WITH  ordara 
IKFLACI  an  WITH  ana 


ordara  ♦  "alraady  exists" 


promote 


IM>00(Nhiie  uaar  doaa  not  antar  blank  for  expert  titla) 


S2F* 

(NhiXauaai 

UF_AW_PU.P1G 


uaar  doaa  not  antar  blank  for  service  nunber.) 
Raturn  to  UPDATE  aanu. 


Nodule  c 
Author 
Data 
Purpose 


.UPAW_PU.PRG 
.KlJir  SAM  NAM 
.22  NOV  M 

■Thia  ia  tha  UPOATI  aodula  for  adding  awarded  and 
punished  nenbers  to  tha  AWARDPUN,  tha  ALPJW,  and 


es _ 

Xt  sal  up  tha  add  award  and  punishment  records  aanu, 
accepts  inptT  ' —  ^ - r— “ 


A_P_P  database  files, 
at  up 


Hit  froai  the  user  and  calls  tha 


Called  by 

Nodules  o _ 

Variables  used 
Global 


required  nodules.  When  control  ia  returned 
fron  the  called  nodule,  the  user  ia  asked  if  more 
information  is  required  and  the  process  ia  repeated, 
or  control  ia  passed  back  to  the  UPOATI  nodule. 


called 


UPDATE 
MINUS CR, 


UPAW.PUl ,  UPAH.PU2,  UPAW.PU3 


NNNNNNNNNNNNNNNN 


i  .  holds  the  value  of  tha  user  input, 
today,  holds  data 

aSaSaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 


AAAAAAAAAAAAA 


CLIAR 

DO  NHXLI  .T. 

*  DO  NHXLI  .T.  naans  DO  NHXLI  TRUt  i.e.  DO  FOREVER 

*  Tha  DO  NHXLI  will  be  terminated  by  an  EXIT  command 

*  Clear  tha  screen  and  display  the  main  menu 

rHINUSCR 

2,11  SAT  "ADD  AWARD  AND  PUNXSHHINT  R  I  , 
CORDS" 
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Ml  "submenu11 
six  "WFORHITIOII" 

s  SIX  -I.  Ilfmrd  and  punishment  point..”  ,  _  „ 

__.jl  SIX  “1.  Idd  personnel  order  of  award  and  punishment." 

12.21  SI X  "C.  Ida  personal  award  and  punishment  record." 

13.21  SIX  ND.  Change  date" 

14.21  SIX  ?X.  tStT 

20,8  SIX  "DITB  TIME" 

20,55  SIX  "UPDITED  BY" 

21,5  SIX  todav 

w  21.19  SI?  TZMtO 
*8  2i.52  SIX  gname 

f  23,10  SIX  "  [  Enter  selection  (  1  -  D,  or  X  to  Exit  )  «  :  ]" 
DO  WHILE  .T. 
i«0 

DO  WHILE  i-0 
INKEY () 

21,19  SIX  TIMEO 
23  54  SIX  "" 

IF  U^FER^CHR(l) )$"IBCDX" 

EMDIF 
i"0 
ENDDO 


wn. 

f 


•  23,54  SIX  OFFER 

if  .wot,  omuls'* 


EXIT 
EMDIF 

SET  COLOR  TO  M7W 
f  19,33  SIX  "INFORHITION" 

•  13,21  SIX  "D.  CHINOS  DITE" 
SET  COLOR  TO  W/N 
8^21,5  GET  today 

!21,S  SIX  today 

19,33  SIX  "IMFORMITION" 

13,21  SIX  "D.  Change  date" 
23,54  SIX  "  " 

ENDDO 
DO  CISI 

CIS!  CHR(1)$  "Xx" 
rt.yie 

RETURN 

CISE  CHR(i)$"Ia" 

DO  UPIWPU1 
CISE  CHR(£)S"Bb« 

DO  UPAWJ?U2 
CISE  CHR(f)$"Cc" 

00  UPIM.F03 
EMDCISE 


JNDDO 

RETURN 


when  done, return  to  main  menu 


7.  UPAWJPU1.PRG 


*  Module  n 

*  Author 

*  Date 

*  Purpose 

* 

* 

* 

* 

* 

* 

*  Called  by 

*  Modules  called 


« UPIW_PU1 . PRO 
:KIM,  SIM  NAM 
>22  NOV  86 

i  This  is  the  UP_AW  PU  module  for  adding  award  and 
punishment  points  to  the  A_P_P  file. 

It  sets  up  the  add  award  and  punishment  points, 
accepts  input  from  the  user  and  calls  the 
required  modules.  When  control  is  returned 
from  the  called  module,  the  user  is  asked  if  more 
information  is  required  and  the  process  is  repeated, 
or  control  is  passed  back  to  the  UP_AW_PU  module. 

>  UPAW  PU 
i  SCBEER5 
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f."  Vf  if  \ 


^  hold*  tka^nlw  of  tha  uwr  input. 

2  tndxy*  holds  dot# 

**********mBHt#**Jl*885t********»****»»»*»**»*******************< 

ff-H-ii1*1 

DO  WXLB  kinds  i  •  ■ 
n» 

2,1  SAT  "Add  award  and  punishnant  points." 

2,60  SAY  today 
2,70  SAY  TIMED 
.  3,0  SAY  ULIME 
? 

— -  Got  proposad  award  and  punishnant  none." 
kinds  »  s?ACX(30) 

•13,3  SAY  "Intar  award  and  punishnant  nana  (prasa  RETURN; 

to  exit)"  GIT  kinds 

READ 

- —  Chock  to  saa  if  award  and  punishnant  nano  alraady  oaists. 

kinds  ■  LOWS* (kinds) 

SISK  kinds 
DO  CASK 

*—...—  if  usar did  not  antar  a  award  and  punishnant  nano, 
claar  tha  scraan  and  raturn  to  UtjMJfV  nanu. 

CASK  kinds  *  "  " 
rr.aaa 

* -  If  avard  and  punishnant  nana  alraady  exists, 

*.......  notify  usar  and  allow  anothar  try. 

CASK  FOUND ()  1 

•  20,10  SAY  kinds  +  "alraady  axists" 

?  CHR(7) 

,  WAIT 

* — - — —  If  award  and  punishnant  nana  not  alraady  takon, 

*— - lot  usar  add  It. 

CASK  .NOT.  FOUND Q 
APPKND  BLANK 
RKPLACX  kind  WITH  kinds 
SET  FORMAT  TO  scraonS 
READ 

SKT  FORMAT  TO 
ENDCASE 

ENDDO(Whila  usar  doas  not  antar  blank  for  award  and  punishnant; 
nana.) 

RE  INDEX 

* —  -------  Raturn  to  UP_AW_PU  nanu. 

RETURi 

2.  UP  A  W_PU2.PRG 

********************************************************************* 

*  Modulo  nana  «UPAW_PU2.PRG 

*  Author  i KIM,  SAM  NAM 

*  Data  ;22  NOV  86 

?  Furposa  sThia  is  tha  UP_AW  PU  modulo  for  adding  tha 

1  personnel  ordar  of  award  and  punishnant  to  tha  AWARDPUN 

?  tils.  It  sots  up  tha  add  parsonnal  ordar  of  award  and 

*  punishnant,  accapts  input  from  tha  usar  and  calls  tha 

*  required  modulo*.  Whan  control  is  raturnad 

.  from  tha  called  modulo,  tha  usar  is  askad  if  more 

2  information  is  raquirad  and  tha  process  is  repeated, 

*  ,,  .  .  or  control  is  passed  back  to  tha  UP_AW_PU  modulo. 

*  Called  by  *  UP  AW  PU 

*  Modules  called  tSCRSEN? 

*  Variables  used  ; 

*  Global  i  i  t  holds  tha  value  of  tha  usar  input. 

*  today;  holds  data 
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1  order  of  award  and  puwiah— nt. " 


tsI#3?Lrr* 


parMDMl  ordor. 

1  ardor  (  or  prooo  RITURM; 


■  LOMU 
mi  award 

DOCJUR 


cut 


SftSriT-  if  personnel  order  already  exists. 

If  uoor  did  not  an tar  a  poraonnal  order, 

Slaar  the  acraon  and  return  to  UPJkMJTO  nanu. 

■  »  • 

n? 


axiata. 


If  paraannal  order  alrc__.  _ 

notify  user  and  allow  another  try. 

^SAY  award  ♦  already  axiata" 


*— — —  |f^pereonn^  order  not  already  taken. 


Ei 


1*000(51 

gpnx 


casi  .weft,  mm 

&mm  tuu 

®Wj.ordar  WITH  award 
HT  POMT  TO  screen! 

Iwrormw  to 
bbcasT 

While  user  doea  not  enter  blank  for  peraonnol  order) 
—  Return  to  OTJttL PU  nonu. 
i.  VP  A  WJHJ3.P&G 


Nodule  naaM  »UPAW_FU3.PR0 
Author  t KIN,  SAN  NAN 

Data  .22  Aov  84 

furpooe  tThia  is  the  UP_AW_PU  nodule  for  adding  personal 
award  ana  punisment  records  to  the  A  Pjtl  file . 

It  sets  up  the  add  personal  award  ana  punishawnt 
records,  accepts  input  from  the  user  and  calls  the 
required  nodules.  When  control  is  returned 
frgn  the  called  nodule,  the  user  is  asked  if  nore 
information  is  required  and  the  process  is  repeated, 
or  control  is  passed  back  to  the  UP_AM_PU  nodule. 

•  Uf_AW_fO 
ailed  ,  none 

Global  i  i  i  holds  the  value  of  the  user  input. 

today,  holds  date 
Local  <  none 

*********£*£********************************************************* 


********* 
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"ter— 

Q«t  proposed  service  number. 

r>  •  SFACE(8) 

19,5  SAT  ''Inter  service  nuaber  <  or  press  RETURN  to  exit)"  GET  sns 

READ 

Check  to  see  if  service  number  already  exists, 
sae  *  LOWER (sns) 

SEEK  sns 
00  rt<T 

*—.....  xf  user  did  not  enter  a  service  nuaber, 

clear  the  screen  and  return  to  UPJkH  _PU  aenu. 

CASE  sns  •  H  " 

CLEAR 

* .  If  service  nuaber  does  not  exist, 

*.......  notify  user  and  allow  another  try. 

CASE  .NOT.  FOUND (} 

f  20,10  SAY  sns  ♦  "does  not  exist" 
f  CH*<7) 

WAIT 

a.......  t£  service  nuaber  already  exists, 

user  add  it. 

CASE  roONDO 

USE  a_p_an  INDEX  a _p  jn 

— — -----  set  up  loop  for  adding  peraonal  award  and 
punishment  records. 

order  *  "x" 

DO  WHILE  order  •  "  " 

CLEAR 

•  2,1  SAY  "Add  personal  award  and  punishaent  records." 

2, SO  SAY  today 
2,70  SAY  ZIHEt) 

3,0  SAY  ULINE 

? 

a...........  (jet  proposed  personnel  order. 

order  •  SPACE (20) 

•  15,5  SAY  "Enter  personnel  order  (or  press  RETURN  to; 

exit)" 

•  IS, 10  SAY  "(e.g  — >86-100  ARHY)"  GET  order 

READ 

*—  Check  to  see  if  service  nuaber  already  exists. 

SEEK  sns 
DO  CASE 

*.......  xf  user  did  not  enter  a  personnel  order, 

a.......  clear  the  screen  and  return  to  previous 

a - prograa. 

CASE  order  ■  "  " 

CLEAR 

a.......  xf  service  nuaber  does  not  exists, 

a.......  sdd  a  personal  award  and  punishment 

a - records  to  A_P_KN  file. 

CASE  .NOT.  FOUND () 

APPEND  BLANK 

REPLACE  p.order  WITH  order 
REPLACE  sn  WITH  sns 

a.......  if  service  nuaber  already  exists  in  the 

a.......  a.PJW  file,  check  to  see  if  personnel 

a.......  order  already  exists  in  the  A_P_MN  file. 

CASS  FOUNDO 
FIND  Asns 
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COPT  TO  tnp  MHZ  LI  sn«"&sns" 

USE  temp 

INDEX  ofi  p_ord«r  TO  temp 
081  temp  iRDEX  tw, 
order  ■  LOWER(order) 

SEEK  order 
DO  CIS! 

CASE  FOUND 0 

9  20,10  SAT  order  +  "already  exists" 

WAIT 

*— — —  If  personnel  order  not  already  taken, 
*— — —  let  user  add  it. 

CASE  .NOT.  FOUND O 

USE  a  D_mn  INDEX  a_p_ran 
appenfBlank 

REPLACE  p_order  WITH  order 
REPLACE  sn  WITH  sns 
ENDCASE 
ENDCASE 

ENDDO (While  user  does  not  enter  blank  for  personnel; 

order.) 

ENDCASE 

CLEAR 

ENDDO (While  user  does  not  enter  blank  for  service  number.) 

Return  to  UP_AW_PU  menu. 

RETURN 

g.  UPEVAL.PRG 

********************************************************************** 

*  Nodule  name  > UPEVAL.PRG 

*  Author  :KIM,  SAM  NAM 

*  Date  :22  NOV  86 

*  Purpose  iThis  is  the- UPDATE  module  for  adding  personal 

*  performance  evaluation  records  to  the  P-EVAL  file. 

*  It  sets  up  the  add  performance  evaluation  records, 

*  accepts-  input  from  the  user  and  calls  the-  required 

*  modules.  When  control  is  returned  from  the  called  module, 

*  the  user  is  asked  if  more  information  is  required  and 

*  the  process  is  repeated,  or  control  is  passed  back  to 

*  the  UPDATE  module. 

*  Called  by  <  UPDATE 

*  Nodules  called  <SCREEN7 

*  Variables  used  « 

*  Global  i  i  <  holds  the  value  of  the  user  input. 

*  todays  holds  date 

**********HffiSSi*******?*********************************************** 

*  Set  up  loop  for  adding  personal  performance  evaluation. 

********** ********* *************************************************** 

USE  main  INDEX  main 
sns  ■  "x" 

DO  WHILE  sns  •  "  " 

!,1  SAT  "Add  personal  performance  evaluation  records." 

J,60  SAT  today 
2,70  SAT  TINE*) 

3,0  SAT  ULINE 

on  proposed  service  number, 
sns  •  SPACE (8) 

|  15,5  SAT  "Enter  service  number  (  or  press  RETURN  to  exit)"  GET  sns 

Check  to  see  if  service  number  already  exists. 

sns  *  LOWER (sns) 

SEEK  sns 
DO  CASE 

*.......  xf  user  did  not  enter  a  service  number. 
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•1/1/  f.M.'  I 

*1  •  #  »  »  •  »  V*  *J  1  » 


clear  the  screen  and  return  to  UPDATE  menu. 

■  UN 


CLtlR 

if  Mrvie*  numbe 
—  notify  wr  and 
CMS  .MOT.  rOURDO 

?  &{?>“* ,n*  *  ■ 


rviee  number  doos  not  exist, 
V  uur  and  allow  another  try. 


records. H 


9  20,10  SAT  ana  *  "does  not  exist." 

WAIT 

xf  service  number  already  exists, 
let  user  add  it. 

CASE  FOUND () 

USE  p_eval  INDEX  p.eval 

Set  up  loop  for  adding  personal 
perforaance  evaluation  records. 

rdate  ■  "x" 

DO  WHILE  rdate  *  "  11 
rr.gaa 

9  2,1  SAT  "Add  personal  performance  evaluation; 


exit)." 


•  2,60  SAT  today 
9  2,70  SAT  TIME*) 

9  3,0  SAT  ULINE 

? 

Get  proposed  rating  date, 
rdate  *  SPACE? 8) 

9  15,5  SAT  "Enter  rating  date  (or  press  RETURN  to; 

9  16,10  SAT  "(e.g - >MM/DD/TT.)"  GET  rdate 

READ 

Check  to  see  if  service  nuaber  already  exists. 

SEEK  sns 
DO  CASE 

if  UMr  did  not  enter  a  rating  date, 
clear  the  screen  and  return  to  previous 
program. 

CASE  rdate  *  "  « 

CLEAR 

a.......  if  service  number  does  not  exists, add 

a.......  s  personal  performance  evaaluation  record 

a -  P  EVAL  file. 

CASE  .NOT.  FOUNCFT) 

APPEND  BLANK 

REPLACE  ratingdate  WITH  rdate 
REPLACE  sn  WITH  sns 
SET  FORMAT  TO  screen7 
READ 

SET  FORMAT  TO 

a-.... —  If  service  number  already  exists  in  the 

*  -  P_BVAL  file,  check  to  see  if  rating 

*  - - —  date  already  exists  in  the  P_EVAL  file. 

CASE  F0UND() 

FIND  &sns 

COPT  TO  temp  WHILE  sn«"&sns" 

USE  temp 

INDEX  ON  ratingdate  TO  temp 
USE  temp  INDEX  temp 
rdate  *  LOWER(rdate) 

SEEK  rdate 
DO  CASE 

CASE  FOUND O 

9  20,10  SAT  rdate  +  "  "  +  "already  exists." 

?  Cl® (7) 

WAIT 

* - If  rating  date  not  already  taken, 

—  let  user  add  it. 

CASE  .NOT.  FOUND 0 

USB  p.eval  INDEX  p_eval 


APPEND  BLANK 

REPLACE  ratinadate  WITH  rdata 
REPLACE  an  WITH  sns 
SET  FORMAT  TO  screen7 
READ 

SET  FORMAT  TO 
EMDCASB 
ENDCASE 

%  ENDDO (While  user  does  not  enter  blank  for  personnel; 

order.) 

ENDCASE 

REINDEX 

CLEAR 

ENDDO (While  user  does  not  enter  blank  for  service  number) 

RETURN 

h.  UPCAREER.PRG 

*4******************************************************************** 
*  Module  name  : UPCAREER.PRG 


*  Author 

*  Date 

*  Purpose 


*  Called  by 

*  Modules  called 

*  Variables  used 

*  Global 


:KIM,  SAM  NAM 
<22  NOV  86 

tThis  is  the  UPDATE  module  for  adding  personal 
military  careers  to  the  CAREERS  file. 

It  sets  up  the  add  assignment  records, 
accepts  input  from  the  user  and  calls  the 
required  modules.  When  control  is  returned 
from  the  called  module,  the  user  is  asked  if  more 
'information  is  required  and  the  process  is  repeated, 
or  control  is  passed  back  to  the  UPDATE  module. 

s  UPDATE 
d  :  SCREEN8 


*  Global  <  i  <  holds  the  value  of  the  user  input . 

*  today:  holds  date 

*  .  Local  <  none 

********************************************************************** 

******************************** 

USE  main  INDEX  main 
sns  *  "x" 

DO  WHILE  sns  #  "  » 

CLEAR 


S2,l  SAT  "Add  assignment  records" 
2,60  SAT  today 
@2,70  SAT  TIME() 


@  3,0  SAT  ULINE 
? 

*- — -- — —  Get  proposed  service  number, 
sns  ®  SPACE (8) 

@15,5  SAT  "Enter  service  number  (  or  press  RETURN  to  exit)"  GET  sns 
READ 

*“ - — — Check  to  see  if  service  number  already  exists. 

sns  *  LOWER (sns) 

SEEK  sns 


DO  CASE 

* _ 

* _ 

CASE  sns 
CLEAR 
* _ 

* _ 


If  user  did  not  enter  a  service  number, 
clear  the  screen  and  return  to  UPDATE  menu. 

a  H  H 


* — -----  if  service  number  does  not  exist, 

* - -  notify  user  and  allow  another  try. 

CASE  .NOT.  FOUND () 

9  20,10  SAy  sns  +  "does  not  exist." 

?  CHR(7) 

WAIT 

— —  If  service  number  already  exists, 
*— — —  let  user  add  it. 

CASE  FOUND () 


exit) 


USX  careers  INDEX  careers  .... 

* — ... - ...  set  loop  for  adding  assignment  records. 

order  *  Mx* 

DO  WHILE  order  #  "  H 
CLEAR 

52,1  SAT  "Add  assignment  records." 

2,60  SAT  today 
2,70  SAT  TIME!) 

3,0  SAT  ULINE 

*- - - — -  Get  proposed  personnel  order. 

order  *  SPACE (20) 

9  15,5  SAT  "Enter  personnel  order  (or  press  RETURN  to; 

9  16,10  SAT  "(e.g  - — >85-100  army)"  GET  order 
READ 

*—  Check  to  see  if  service  number  already  exists. 

SEEK  sns 
DO  CASE 

*— — —  If  user  did  not  enter  a  personnel  order, 

* — — —  clear  the  screen  and  return  to  previous 
* — .. — -  program. 

CASE  order  ■  "  " 

CLEAR 

*— — —  If  service  number  does  not  exists, add 
— —  a^ersonal  asignment  record  to  CAREERS 

CASE  .NOT.  FOUND () 

APPEND  BLANK 

REPLACE  p_order  WITH  order 
REPLACE  sn  WITH  sns 
SET  FORMAT  TO  screen8 
READ 

SET  FORMAT  TO 

if  servi ^e  number  already  exists  in  the 
—  CAREERS  file,  check  to  see  if  personnel 
order  already  exists  in  the  CAREERS  file. 

CASE  FOUND() 

FIND  &sns 

COPT  TO  temp  WHILE  sn»"&sns" 

USE  temp 

INDEX  ON  p_order  TO  temp 
USE  temp  INDEX  temp 
order  =  LOWER(order) 

SEEK  order 
DO  CASE 

CASE  F0UND() 

9  20,10  SAT  order  +  "  "  +  "already  exists." 


9  20,10  SAT  order  +  "  "  +  "already  exists." 

?  CHR(7 ) 

WAIT 

*  - -  if  personnel  order  not  already  taken, 

*  - —  let  user  add  it. 


CASE  .NOT.  FOUND () 

USE  careers  INDEX  careers 
APPEND  BLANK 

REPLACE  p_order  WITH  order 
REPLACE  sn  WITH  sns 
SET  FORMAT  TO  screen8 
READ 

SET  FORMAT  TO 
ENDCASE 
ENDCASE 

ENDDO (While  user  does  not  enter  blank  for  personnel; 

order.) 

ENDCASE 

CLEAR 

ENDDO(While  user  does  not  enter  blank  for  service  number) 

*- . Return  to  UPdDATE  MODULE. 


RETURN 


6.  EDIT.PRG 


********************************************************************* 

*  Module  name  « EDIT. PRO 

Author  i PARK.  JAE  BOCK 

Date  life  NOV  8fe 

Purpose  i This  is  the  DRIVER  module  for  the  EDIT  function 

It  sets  up  the  main  edit  menu,  accepts  input 
from  the  user  and  calls  the  required^ modules. 

When  control  is  returned  from  the  called  module, 
the  user  is  asked  if  more  information  is  required 
and  the  process  is  repeated  or  control  is  passed 
back  to  the  DRIVER  module. 


Called  by 
Modules  called 

Variables  used 
Global 


DRIVER 
sMENUSCR, 
EDPUNISH, 


EDEXPERT,  EDEDUCAT,  EDPROMOT,  EDAWARD, 
EDEVAL,  EDCAREER 


i  t  holds  the  value  of  the  user  input, 
today  :  holds  date 
Local  t  none 

********************************************************************** 

*  ^  Set  UP  1°°P  for  presenting  menu. 

********************************************************************** 


CLEAR 

DO  WHILE  .T. 

CLEAR 

DO  MENUS CR 

@  2,20  SAY  "EDIT  PERSONNEL  RECORD" 

@6,34  SAY  "SUBMENU" 

@  19  33  SAY  "INFORMATION" 

@  9,5  SAY  "A.  Edit  personal  personnel  record." 

@10,5  SAY  "B.  Edit  expert  record." 

@11,5  SAY  "C.  Edit  military  education" 

@12,8  SAY  "  result." 

@13,5  SAY  "D.  Edit  promotion  record." 

@14,5  SAY  "E.  Edit  award  and  punishment  record." 

@  9,42  SAY  "F.  Edit  performance  evaluation" 

@  10,45  SAY  "  record^. " 

@  11,42  SAY  "G.  Edit  assignment  record." 

@  13,42  SAY  "I.  Change  date" 

@  14,42  SAY  "X.  Return  to  main  menu" 

@20,8  SAY  "DATE  TIME" 

@  20,55  SAY  "UPDATED  BY" 

@21,5  SAY  today 
@  21,19  SAY  TIME() 

*@  21,52  SAY  gname 

@  23,10  SAY  "fEnter  selection  (A  -G,  I,  or  X  to  return  to  main" 
@  23,57  SAY  "menu)  i  ; 

DO  WHILE  .T. 
i=0 

DO  WHILE  i=0 
i»INKEY() 

@  21,19  SAY  TIME() 

9  23,65  SAY  "" 

IF  UPPER(CHR(i))$"ABCDEFGIX" 

EXIT 

END  IF 
i*0 
ENDDO 

@  23,65  SAY  UPPER(CHR(i) ) 

IF  .NOT.  CHR(i)$"Ii" 

EXIT 

ENDIF 

SET  COLOR  TO  N/W 

§19,33  SAY  "INFORMATION" 

13,42  SAY  "I.  CHANGE  DATE" 


IT  COLOR  TO  tf/N 
i  21,5  OCT  today 


SAT  today 
SAY  "INTOKMATION" 


i  13,42  SAY  ttX.  Chang*  data" 
23,65  SAY  ■  " 

ENDDO 
DO  CASE 

CASK  CHR(1)$  "Xx“ 

CLEAR 

RETURN 

CASE  CHR(i)$"Aa" 

DO  EDNA IN 
CASE  CHR(i)$"Bb" 

DO  EDEXPERT 
CASE  CHRU)$"Cc" 

DO  EDEDUCAT 
CASE  CHR(i)$"Dd" 

DO  EDPROMOT 
CASE  CHR(i)$"Ee" 

DO  ED  Xw  PU 
CASE  CHmJV'Ff" 

DO  EDEVAL 
CASE  CHR(i)$"Gg" 

DO  EDCAREER 
ENDCASE 
ENDDO 

* - when  done,  return  to 

RETURN 

a.  EDMAIN.PRG 


return  to  main  menu. 


****************************ik**************************************** 

*  Nodule  name  : EDMAIN.PRG 

*  Author  >PARK,  JAE  BOCK 

*  Date  >22  NOV  86 

*  Purpose  sThis  is  the  EDIT  module  for  editing  personnel  record. 

*  It  sets  up  the  edit  prsonal  personnel  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,  the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDIT  module. 

*  Called  by  >  EDIT 

*  Nodules  called  >SCREENU 

*  Variables  used  > 

*  Global  >  i  <  holds  the  value  of  the  user  input. 

*  today >  holds  date 

*  Local  :  none 

A**************************** ***************** ************************ 

*  Set  up  loop  for  editing  personnel  record. 
********************************************************************** 

USE  main  Index  main 
sns  *  "x" 

DO  WHILE  sns  *  "  " 

* - - —  find  out  what  service  number  to  edit. 

CLEAR 

9  2,1  SAY  "EDIT  PERSONNEL  RECORD" 
f  2,60  SAY  today 
9  2,70  SAY  TIMEU 
9  3,0  SAY  ULINE 


* -  Get  proposed  service  number. 

sns  *  SPACE (8) 

9  15,5  SAY  "Edit  for  what  service  number  (  or  press  RETURN; 
to  exit)"  GET  sns 

READ 

*-- — — — —  Try  to  find  that  service  number. 


■  LOWER (sns) 

SSSK  «ns 
DO  CUE 

........  if  do  s«rvict  number  entered,  rttura  to  EDIT 

CUE  ins  •  •  " 

CT.»ift  _ 

* — - - if  sorviet  number  found,  odit  using  SCUIN1  foi 

CUE  FOUND?)  ' 

SET  FORMAT  TO  scroonll 
HEAD 

SET  FORMAT  TO 

otherwise,  warn  user  and  allow  another  try. 
CUE  .NOT.  FOUND?) 

«17,5  SAY  “Inara  is  no  “  +  sns  ♦  "number." 

24,5  SAY  MFrass  any  kay  to  try  again..." 

WAIT  "  " 

ENDCASE 

ENDDO( Continue  editing  until  user  requests  exit) 

* — — -  Return  to  EDIT  menu. 

RETURN 

b.  EDEXPERT.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 

* 

A 

* 

A 
A 
A 
A 
A 
A 
A 
A 


Called  by  < 
Modules  called  t 
Variables  used  : 

Global  t 


:  EDEXPERT.PRG 
i RIM,  SAM  NAM 
<22  NOV  86 

iThis  is.  the  EDIT-  nodule  for  editing  an  expert  record. 
It  sets  up  the  edit  expert  record,  accepts  input  from 
the  user  and  calls  the  required  modules. 

When  control  is  returned  from  the  called  module, 
the  user  is  asked  if  more  information  is  required  and 
the  process  is  repeated,  or  control  is  passed  back 
to  the  EDIT  module. 

EDIT 
SCREEN9 


Local  i  none 

kAAAAAAAAAAAAA 


i  j  holds  the  value  of  the  user  input, 
today r  holds  date 


***********  I$aa!&a£^&aa$aaa^a£a£aaaa$a$aS£aaaS25$Aaa  **************** 
USE  expert  INDEX  expert 
title  *  "x“ 
sns  *  "x" 

DO  WHILE  sns  #  "  "  .AND.  title  *  "  " 

a -  pind  out  what  service  number  to  edit. 

CLEAR 

9  2,1  SAY  "EDIT  EXPERT  RECORD" 

§2,60  SAY  today 
2,70  SAY  TIME() 

9  3,0  SAY  ULINE 
? 

? 

a - Get  proposed  service  number. 

title  *  SPACE (20) 
sns  *  SPACE (8) 

@  15,5  SAY  "Edit  for  what  service  number  (  or  press  RETURN; 
to  exit)"  GET  sns 
READ 

9  15,5  SAY  "Edit  for  what  expert  title 
to  exit)"  GET  title 
READ 

a - - -  Try  to  find  that  service  number. 

sns  ■  LOWER (sns) 

SEEK  sns 
DO  CASE 

a -  If  no  sarvice  number  entered,  return  to  EDIT  menu. 

CASE  sns  ■  "  " 


(  or  press  RETURN; 
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«  «  «  « 


Pit* 


the 


it 

ts.  It  Mti  up  the  edi €  ■ilitary  education 
accepts  input  free  the  uaar  and  calls  tha 
■adults.  Mhon  central  is  retur*d 
,  „  called  nodule,  t he  user  is  asked  if  nore 
information  is  required  and  the  process  is  repeated, 
or  control  is  passed  back  to  the  IDKDtfCAT  nodule. 

- IT  ^ 

1 


holds  tha  value  of  the  user  input. 
~i  holds  date 


*************** 


it  Index  a_educat 
class  ■»  "at* 

DO  MRU  class  •  M  H 

*....... —  rind  out  vhat  class 


to  edit. 


MY  HCDIT  HILITAIY  IDUCATION  RISULTS" 
MY  today 

'JhZV> 


152 


aeeaeeeaeeaeaeeee 


T-  ‘spessi  elm 

_  ««l^eiiiMr  *****  cl*M  MM  ^  •*  Pr***  *Bruw*» 

--Try  to  find  that  claia  mm. 
class  •  UNU(el*M> 

if  no  elasa  mm  antarad,  raturn  to  KDCIT  manu. 

CISS  elaaa  *  "  " 

CLKJJt 

a.......  if  elaaa  mm  found,  adit  using  SCSIKNl  format. 

CISS  fOWD?) 

SIT  rOBAT  TO  screenSl 

mo 

HI  fOBAT  TO 

otharvisa , warn  uaar  and  allow  another  try. 

CISS  .NOT.  root©!) 

•  17,5  SIT  "There  ia  no  "  +  claaa 
|24,5  SIT  "Frees  any  key  to  try  again..." 

IMDOO( Continue  editing  until  uaar  raquaata  exit.) 

— ■ —  Saturn  to  KDCIT  menu. 

2.  EDJ4JED2JRG 

Module  mm  *K0JHD2.FS0 
luthor  (KXM,  SIM  MIH 

Data  ,22  NOV  84 

Purpose  iThis  ia  the  KOKDCIT  module  for  editing  personal 

education  results. 

It  aata  up  the  edit  peraoMl  education  raault, 
accepts  input  from  the  user  and  calls  the 
required  nodules.  When  control  is  returned 
from  the  called  nodule,  the  user  is  asked  if  aori 
information  is  required  and  the  process  is  repeated, 
or  control  is  passed  beck  to  the  KOKDCIT  module. 
Called  by  >  KOKDCIT 
Modules  called  *  SCKSSN21 
Variables  used  i 

•label  t  i  t  holds  the  value  of  the  user  input, 
today i  holds  date 

OKI  edueatmn  IMDKX  educatmn 
mm  * 

SM  *  MXM 

DO  NHXLK  sm  •  ■  "  .OS.  MM  •  "  " 

Find  out  what  service  number  to  edit. 

JU 

2.1  SIT  "IDZT  FKSSOMIL  EDUCATION  SSSULTS" 

2,40  UT  today 
2,70  UT  TXHST) 

1,0  UT  ULZNK 

I - ... -  oat  proposed  service  number  and  class  name. 

MM  ■  SUCK  (20)  r 

ins  •  SPACE To ) 

15,5  UT  "Edit  for  what  service  number 
"  OR  am 
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^•V 


sg:f  m  vs  Afiuiavs;)' 

Try.  to  find  that  service  number. 

«W  •  LOWS! (sns) 

£».....  if  M  service  number  entered,  return  to  U>XT  menu. 

ref  yin  ■  m  n 

PT.f ■ 

CUI  neae  *  "  H 

rr.Tiw 

— If  service  number  found,  try  to  find  thet  cless  neae 

* - and  edit  using  screen2l  format. 

CASK  FOtJHD  () 

USX  educatan  INDEX  ccnaae 
sns  *  sns  +  neae 
sns  *  lower (sns) 

SEEK  sns 
IF  FOUNDQ 

SET  FORMAT  TO  screen21 
READ 

SET  FORMAT  TO 
ELSE 

{5,0  green 

15,5  SAT  neae  +  "  Not  found" 

?  Ott(V> 

WAIT 

ENDIF 

* — -  Otherwise, warn  user  end  allow  another  try. 

CASE  .NOT.  FOUND?) 

J17,5  SAT  "There  is  no  "  ♦  sns 

24,5  SAT  "Press  any  key  to  try  again..." 

WAIT  "  " 

endcase 

XMDD0( Continue  editing  until  user  reguests  exit.) 

Return  to  EDEDCAT  menu. 

RETURN 

d.  EDPROMOT.PRG 


Module  neae 
Author 
Date 
Purpose 


A 
* 

* 

* 

* 

A 
A 
A 
A 
A 
A 
A 
A 
A 
A 
A 

******** 

A 

A*  ********* 


Called  by 
Modules  called 
Variables  used 
Global 


s EDPROMOT.PRG 
iKIM,  SAM  NAM 
>22  NOV  86 

(This  is  the  EDIT  nodule  for  editing  proaotion 
records.  It  sets  up  the  edit  proaotion  record, 
accepts  input  froa  the  user  and  calls  the 
required  nodules.  When  control  is  returned 
froa  the  called  module,  the  user  is  asked  if  more 
information  is  required  and  the  process  is  repeated, 
or  control  is  passed  back  to  the  EDIT  nodule. 


**$&£Si* ****$$£ 


EDIT 
none 

i  <  holds  the  value  of  the  user  input, 
todays  holds  date 


*********************************************** 


A AAAAAAAA AAAAAAAA* 


CLEAR 

DO  WHILE  .T. 

*  DO  WHILE  .T.  naans  DO  WHILE  TRUE  i.e.  Do  forever. 

*  The  DO  WHILE  will  be  terminated  by  an  EXIT  command. 

*  Clear  the  screen  and  display  the  main  menu. 

DO  MINUS CR 

I  2,12  SAT  "EDIT  PRM0TI0N  RECORD" 

*  6.36  SAT  "SUBMENU" 

i  19,33  SAT  "INFORMATION" 
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vurasi 


tar  aalaction  (  A  -  C,  or  X  to  Knit  )  *  «  ] ' 


ffit?  H“<> 

o*m<q*(i)  )iMiscr 


55" 

^tn 

MTICOLOK  TO  N/W 

nilTa?  "FaS8iaSL 


l  COLOt  TO  W/M 
tlTs  0«T  today 


DATS" 


l  J]%%oMinor 
l:  ,21  SAT  "C.  Changa^ata" 
23,34  SAT  -  " 


tMPOQ 


ittCMR<i)S  NX«M 

tf1qfciM*Aa« 
a  SfmPsb- 

DO  IDf«KM02 


At  turn  t*  IDXT  oanu. 


I.  EDPROMOLPMG 


Author 

Data 

rurpooa 


i.no 


ia  tha  IDTHOHOT  oodula  tor  editing  promotion 
rd.  Tt  eat  a  up  tha  adit  proootion  racord, 
aecapta  input  rroo  tha  uaar  and  calla  tha 
required  oodulaa .  Whan  control  ia  ratumad 


required  ooguiea.  whan  control  ia  ratumad 
trm  tha  called  oodula.  tha  uaar  ia  aaked  if  aora 
information  ia  required  and  tha  procaaa  ia  repeated, 
or  control  ia  paaaod  bach  to  tha  tDPMHOT  oodula. 

i  f&TBCttOf 

i  isaotiMi 

I  I 

«i«  ho Ida  tha  valua  of  tha  uaar  input, 
today i  holda  data 


Sat  up  loop  for  editing  PnoNOTlOM  racord. 


135 


•Nir  to  adit. 


T 


Hpwywk  promotion  order. 

It  for  what  preaetion  order  (  or  proto  RKTURM; 
order 


order  ■  umu( order; 

8“^ 

if  no  promotion  01 

at—  ■  ■  * 

* . —  If  proswtiea  ordei 

cm  foohoq 

&T  VOMIT  TO  eeroondl 
SKT  FORMAT  TO 


tion  order. 


tion  order  entered,  return  to  KDPKOHOT  oenu. 


etion  order  found,  edit  using  SCRUMS  format . 
screeaSi 


— ■ -  0 the rvise, warn  user  end  allow  another  try. 
.NOT.  POUND () 

$%  SAT  "There  ie  no  "  ♦  order 
!4,S  SAT  "Trees  any  key  to  try  again. 


KMDOO( Continue  editing  until  user  requests  exit.) 
Saturn  to  KDPKOHOT  menu? 


2.  EDPK0M02.FMG 


*  Module  nasM  iPPNOHO 

*  Author  i KIM,  S 

*  Data  i 22  MOV 

*  Purpose  i This  is 

:  nsX 

*  require 

*  frosi  th 

*  informs 

*  or  cent 

*  Called  by  «  KDPKOHOT 

*  Hodules  called  i 

*  Variables  used  i 

*  Global  i  i  i 

*  tods 

*  Oak  ub  Iaob 


tSwnOH02.PM 
.KIM,  SAW  NAM 
,22  MOV  84 

■This  is  the  KDPKOHOT  nodule  for  editing  personal 
proawtion  record. It  sets  up  the  edit  personsl  promotion 
record,  accepts  input  fron  the  user  and  calls  the 
requires,  nodules.  When  control  is  returned 
fron  the  called  nodule,  the  user  is  asked  if  more 
information  is  required  and  the  process  is  repeated, 
or  control. is  passed  back  to  the  KDPKOHOT  nodule. 


>«%B  S 

•4  t 

•1  i  i  i  holds  the  value  of  the  user  input, 
today i  holds  date. 


(********** 


USX  prosmte  INDEX  pronrte 
order  •  "s" 
sns  *  "a" 

DQMH1LR  sns  «  "  "  .OK.  order  •  "  " 

Find  out  what  service  masher  to  edit. 


Hi 


SAT  "KDIT  PKKSONAL  PROMOTION  RK CORDS" 
SAT  today 
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i  m* jmb° 

tjjj .prapaea i  service  maker  mi  pronotlon  order. 
n»,lWl4f  for  dot  ooririeo  awbtr  . 

0!:?  18  Tie  WStSrU°S»!?tSr«  order 

Iff? - Try  I 

(«*> 


»0r 


prtu 

Try  to  find  that  oorvico  nunber. 


It  no  oorvico  nunber  onto rod,  return  to  BDPROMOT  nonu. 


M  M 

order  «  »  * 


*--— --If ^service  n^obor^found,  try  to  find  thet  pronotion 

dSTfowSfr  *  *' 


RB  pnaoo to  Mm  p.order 
*  km  *  one  ♦  order 
wm  •  lower  (one) 
ftps  one 
If  ftfflNDQ 

gJDfd,,ai 

at 


TO  screoalO 
TO 

order  ♦  "  Not  found" 


ixr 

—  Othorwl^.varn  user  end  allow  another  try. 


T$. 


fjTVf  UT  "There  is  no  "  ♦  sns 
(L|4,5  SAT  "frees  any  key  to  try  again..." 


SUMO  (Continue  editing  until  user  requests  exit.) 
*— - - --Return  to  CDftonOT  nenu. 

e.  tDjkW.PU.PtG 


Author 

Dote 

fuepoeo 


Soiules^elled 
Veriebles  used 
Global 


LftJ.flO 

SAM  HAM 

MOV  M 

s  is  the  BDIT  nodule  for  editing  award  end  punishment 
record.  It  sets  up  the  edit  award  end  punishment  record, 
accepts  input  fron  the  user  end  calls  the 
i ed  modules.  When  control  is  returned 
-.  the  celled  nodule,  the  user  is  asked  if  nore 

_ onset ion  is  required  end  the  process  is  repeated, 

or  control  is  passed  back  to  the  EDIT  nodule. 


EDIT 


i  :  holds  the  value  of  the  user  input, 
today i  holds  date 
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Vo yi.y/  yv 


•  '’S'’  VTrfy^tVrvv 


*!®sL8ss&* 


MMM 


CLEAR 

^dTSSle’It.  Mini  DO  HHZLK  TROT  i.a.  DO  FOREVER 

•  The  DO  WHILE  will  ba  terninated  by  an  EXIT  command 

•  Claar  tha  scraan  and  display  tha  main  nanu 
DO  MENUS CR 

•2,12  SAY  "EDIT  AWARD  PUNISHMENT  RECORD  " 

§  6,36  SAT  "SUBMENU" 

•  19,33  SAT  "INFORMATION" 

0  10,21  SAT  "A. Edit  award  and  punishnant  points." 

•  11,21  SAT  "B.Edit  award  and  punishment  record." 

•  12,21  SAT  "C.Edit  personal  award  and  punishment  record." 

•  13,21  SAT  "D. Change  date." 

§  14,21  SAT  "X.Exit" 

•20,8  SAT  "DATE  TIME" 

•  20,55  SAT  "UPDATED  BT" 

§  21,5  SAT  today 

•  21.19  SAT  TIME<) 

*@  21.52  SAT  gname 

•  23,10  SAT  "  [  Enter  selection  (  A  -  D,  or  X  to  Exit  )  :  «  ]" 
DO  WHILE  .T. 

i*0 

DO  WHILE  i*0 
i»INKET< ) 

t  21,19  SAT  TIME() 

23,54  SAT  "" 

IF  UPPER(CHR(i))$"ABCDX" 

EXIT 

ENDIF 

i»0 

ENDDO 

@  23,54  SAT  UPPER(CHR(i)) 

IF  .NOT.  CHR(i)$"Dd" 

EXIT 

ENDIF 

SET  COLOR  TO  N/W 
0  19,33  SAT  "INFORMATION" 

•  13,21  SAT  "D.  CHANGE  DATE" 

SET  COLOR  TO  W/N 
•  21,5  GET  today 
READ 

•  21,5  SAT  today 
0  19,33  SAT  "INFORMATION" 

0  13,21  SAT  "D.  Change  date" 

•  23,54  SAT  »  " 

ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 

CLEAR 

RETURN 

CASE  CHR<i)$"Aa" 

DO  EDAW  PU1 
CASE  CHR(l)$"Bb" 

DO  EDAW JPU2 
CASE  CHR(f)$"Cc" 

DO  EDAW_PU3 
ENDCASE 
ENDDO 

Return  to  EDIT  nanu. 

RETURN 

1.  EDAW  PU1.PRG 


Raturn  to  EDIT  nanu. 


iMMHMMW************************************************************** 

*  Module  name  :EDAW_PU1 .PRG 

*  Author  iKIM,  SAM  NAM 

*  Data  >22  NOV  86 

*  Purpose  tThia  ia  tha  EDJMf_PU  nodule  for  editing  award  and 


*  punishment  ponits.  It  sets  up  the  «dit  award  and 

*  punishment  points,  accapta  input  from  the  user  and 

*  calls  quirea  nodules.  Whan  control  is  returned 

*  from  the  called  nodule.  the  user  is  asked  if  more 

*  intonation  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  ED_AW_PU  nodule. 

*  Called  by  t  SDAW  PU 

*  Modules  called  *  ScKeeHSI 

*  Variables  used  < 

*  Global  t  i  i  holds  the  value  of  the  user  input . 

*  today:  holds  date 

*  Local  :  none 

********************************************************************** 

***************1S****8***********?***********8**********5************* 

USE  a  o  o  Index  a_p_p 
award  »^x" 

DO  WHILE  award  t  11  " 

* - Find  out  what  award  and  punishment  point  to  edit. 

CLEAR 

f2,l  SAY  '‘EDIT  AWARD  AND  PUNISHMENT  POINTS” 

2,60  SAY  today 
@2,70  SAY  TIMEO 
@3,0  SAY  ULINE 

? 

* - . —  Get  proposed  type  of  award  and  punishment. 

award  *  SPACE (30) 

@15,5  SAY  "Edit  for  what  kind  of  award  and  punishment” 

@  16,7  SAY  ”(  or  press  RETURN  to  exit)”  GET  award 
READ 

*---- — —  Try  to  find  that  kind  of  award  and  punishment, 
award  *  LOWER(award) 

SEEK  award 
DO  CASE 

* - If  no  kind  of  awardand  punishment  entered, 

* — — —  return  to  ED_AW„PU  menu. 

CASE  award  »  ”  ” 

CLEAR 

* - If  kind  of  award  and  punishment  found, 

* — — —  edit  using  SCREEN5  format. 

CASE  FOUNDQ 

SET  FORMAT  TO  screenSl 
READ 

SET  FORMAT  TO 

*— — - —  otherwise, warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND () 

CLEAR 

@17,5  SAY  "There  is  no  "  +  award 
@  24,5  SAY  "Press  any  key  to  try  again..." 

WAIT  "  " 

END CASE 

ENDDO( Continue  editing  until  user  requests  exit.) 

*. — .......  Return  to  ED_AW_PU  menu. 

RETURN 

2.  EDA  WJPU2.PRG 

********************************************************************* 
*  Module  name  :EDAW_PU2.PRG 

*  Author  i KIM,  SAM  NAM 

*  Date  : 22  NOV  86 

*  Purpose  :This  is  the  ED_AW_PU  module  for  editing  award  and 

*  punishment  records . 

*  It  sets  up  the  edit  award  and  punishment  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,  the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  ED^AW_PU  module. 
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*  Variables  used  t 

*  Global  i  i  t  bolds  tho  vsluo  of  tho  user  input. 

*  todays  holds  data 

a  Tjtesl  «  naiM 


*  .  Sat  up  low  for  editing  award  and  punishment  point. 

aaasa*aeaeaaaaai3saaw*w*wai^*jwaa*ea*******a**aaaa***a*a*a*aaaa******** 

USE  awardpun  Index  avardpun 
award  ■  "xM 
DO  WHILE  award  *  11  11 

Find  out  what  award  end  punishment  record  to  edit. 

fT.nap 

!2,1  SET  "EDIT  AWARD  AND  PUNISHMENT  RECORDS" 

2,60  SAT  today 
2,70  SAY  TIMET) 

3,0  SAT  ULINE 

? 

Get  proposed  PRSONNEL  ORDER, 
awerd  ■  SPACE (20) 

S15,5  SAT  "Bait  for  whet  personnel  order" 

16,7  SAT  "(  or  press  RETURN  to  exit)"  GET  award 
READ 

Try  to  find  that  personnel  order, 
award  LOWER  (award) 

SEEK  award 
DO  CASE 

* -  If  no  personnel  order  entered, return  to  ED  AW  PU  menu. 

CASE  award  *  "  ” 
rattan 

* — -----  if  personnel  order  found,  edit  using  SCREEN61  format. 

CASE  FOUND?) 

SET  FORMAT  TO  screen61 

READ 

SET  FORMAT  TO 

* - Otherwise,  warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND() 

CLEAR 

}17,5  SAT  "There  is  no  "  +  award 

24,5  SAT  "Press  any  key  to  try  again..." 

WAIT  "  " 

END CASE 

ENDDO( Continue  editing  until  user  requests  exit.) 

Return  to  ED_AW_PU  menu. 

RETURN 

3.  EDA  W_PU3.PRG 

********************************************************************** 

*  Module  name  sEDAW_PU3 .PRG 

*  Author  <K1M,  SAM  NAM 

*  Date  i 22  NOV  86 

*  Purpose  <This  is  the  ED_AW_PU  module  for  editing  personal 

*  award  and  punishment  records. 

*  It  sets  up  the  edit  personal  award  and  punishment  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,  the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  .  or  control  is  passed  back  to  the  ED_AW_PU  module. 

*  Called  by  «  ED_AW_PU 

*  Modules  called  t  none 
*  Variables  used  i 

*  Global  t  i  i  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local  :  none 


Set  up  loop  for  editing  personal  award  and  punishment  record. 


OSX  a_p_mn  INDEX  »{>_■" 

©rasr*"*" 

d  a  "ji** 

DO  WHILE  sns  *  "  "  .OR.  order  *  "  " 

*— - — •  Find  out  what  service  maker  to  edit. 

|2Vl  SAT  “EDIT  PERSONAL  AWARD  AND  PUNISHMENT  RECORDS.11 
§  2,60  SAT  today 

•  2,70  SAT  TIMET) 

•  3,0  SAT  ULINE 
? 

? 

*- - - -  Get  proposed  service  number  and  personnel  order. 

order  *  SPACE (20) 
sns  ■  SPACE (8) 

§  15,5  SAT  "Sait  for  what  service  number  ; 

"  GET  sns 

pxan 

?17,5  SAT  "Edit  for  what  personnel  order  11 

18,7  SAT  "(  or  press  RETURN  to  exit)  "  GET  order 

READ 

*- - Try  to  find  that  service  number. 

sns  *  LOWER(sns) 

SEEK  sns 
DO  CASE 

If  no  service  number  entered,  return  to  ED  AWJPU  menu. 
CASE  sns  »  11  11 
CLEAR 

CASE  order  ■  "  " 

CLEAR 

Xf  service  number  found,  try  to  find  that  personnel 
order  and  edit  it. 

CASE  FOUND () 

USE  ajp_mn  INDEX  a _p_mns 
sns  *  sns  ♦  order 
sns  »  lower (sns) 

SEEK  sns 
IF  FOUND 0 

SET  FORMAT  TO  screenl2 
READ 

SET  FORMAT  TO 
ELSE 

tS , 0  CLEAR 

15,5  SAT  order  +  "  Not  found" 

?  dm(7) 

WAIT 
END  IF 

* - —  Otherwise, warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND() 

PT-PSP 

*17,5  SAT  "There  is  no  "  +  sns 

24,5  SAT  "Press  any  key  to  try  again..." 

WAIT  "  " 

ENDCASE 

ENDDO( Continue  editing  until  user  requests  exit.) 

*- - Return  tO  ED_AW„PU  menu. 

RETURN 

f.  EDEVAL.PRG 


jRMAT  TO  screenl2 


********************************************************************** 

*  Module  name  : EDEVAL.PRG 

*  Author  1 KIM,  SAM  NAM 

*  Date  1 22  NOV  86 

*  Purpose  iThis  is  the  EDIT  module  for  editing  performance 

*  evaluation  records. 

*  It  sets  up  the  edit  performance  evaluation  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 


ww* 


*  fro*  the  called  module,  the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDIT  module. 

*  Called  by  «  EDIT 

*  Modules  called  >  SCREEH71 

*  Variables  used  < 

*  Global  t  i  >  holds  the  value  of  the  user  input. 

*  todays  holds  date 

*  Set  up  loop  for  editing  performance  evaluation  record. 

USE  p_eval  INDEX  p_eval 
rdate  »  "x" 
sns  ■  "x11 

DO  WHILE  sns  #  11  "  .OR.  rdate  #  11  11 

*- - -  Find  out  what  service  number  to  edit. 

CLEAR 

@  2,1  SA7  "EDIT  PERSONAL  PROMOTION  RECORDS" 

@2,60  SAT  today 
#2,70  SAY  TIMEt) 

@  3,0  SAY  ULINE 

9 

? 

*—————  Get  proposed  service  number  and  promotion  order, 
rdate  -  SPACE (8) 
sns  •  SPACE  (.8) 

@15,5  SAY  "Edit  for  what  service  number  . 

"  GET  sns 
READ 

@  17,5  SAY  "Edit  for  what  rating  date  (e.g - >  03/10/86" 

@18,7  SAY  "  (  or  press  RETURN  to  exit)  "  GET  rdate 

READ 

*------ -  Try  to  find  that  service  number. 

sns  *  LOWER(sns) 

SEEK  sns 
DO  CASE 

—  if  no  service  number  entered,  return  to  EDIT  menu. 
CASE  sns  *  "  " 

CLEAR 

CASE  rdate  ■  "  " 

CLEAR 

"———If  service  number  found,  try  to  find  that  rating 
date  and  edit  it. 

CASE  FOUND () 

USE  p.eval  INDEX  rating 
sns  *  sns  +  rdate 
sns  ■  lower (sns) 

SEEK  sns 
IF  FOUND () 

SET  FORMAT  TO  screen71 
READ 

SET  FORMAT  TO 
ELSE 

15,0  pt-RIB 

15,5  SAY  rdate  ♦  "  Not  found" 

?  CWt(7) 

WAIT 

ENDXF 

Otherwise, warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND () 

CLEAR 

J17,5  SAY  "There  is  no  "  ♦  sns 

24,5  SAY  "Press  any  key  to  try  again..." 

utTT  mm  m  * 

END CASE 

ENDOO( Continue  editing  until  user  requests  exit.; 

Return  to  EDIT  menu. 
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f.  EDCAKEEX.PKG 


*  Netful*  mm  .EDCAREEl.PRG 

*  Author  i RIM,  SAM  NAN 

*  Date  i 22  NOV  M 

*  Purpose  i This  is  tho  IDIT  module  for  editing  personal 

*  assignment  records. 

*  It  sets  up  the  edit  personal  assignment  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,  the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDIT  module. 

*  Called  by  t  IDIT 

*  Nodules  called  :  SCREEN81 

*  Variables  used  : 

*  Global  t  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local  :  none 

****************************  *************************** ************** 

*  Set  up  loop  for  editing  assignment  record. 

ee*e**<Mtr***<wkAe*lkeeeeRee*e*e*****Ke***ikjf****i*****i[:<t****************** 

USE  careers  INDEX  careers 
order  »  "x" 
sns  «  "x“ 

DO  WHILE  sns  *  "  "  .OR.  order  #  "  " 

*— — - Find  out  what  service  number  to  edit. 

2,1  SAT  “EDIT  PERSONAL  ASSIGNMENT  RECORDS'1 
2,60  SAT  today 
2,70  SAY  TINE(> 

3,0  SAT  ULINI 

? 

? 

— -  Get  proposed  service  number  and  personnel  order, 
order  *  SPACE (20) 
sns  «  SPACE (8) 

•  15,5  SAT  ’‘Edit  for  what  service  number  . 

H  GET  sns 

■■an 

J17,5  SAT  "Edit  for  what  personnel  order” 

18,10  SAT  "  (  or  press  RETURN  to  exit)  "  GET  order 

READ 

*„ — - - Try  to  find  that  service  number. 

sns  *  LOWER ( sns) 

SEEK  sns 
DO  CASE 

jf  no  service  number  entered,  return  to  EDIT  menu. 

CASE  sns  *  "  " 

CLEAR 

CASE  order  ■  "  " 

CLEAR 

*— — If  service  number  found,  try  to  find  that  personnel 

*- - -  order  and  edit  it. 

CASE  FOUND ( ) 

USE  careers  INDEX  career 
sns  *  sns  *  order 
sns  ■  lower (sns) 

SEEK  sns 
IF  FOUND Q 

SET  FORMAT  TO  screen81 

READ 

SET  FORMAT  TO 
ELSE 

f  5.0  CLEAR 

•  15,5  SAY  order  ♦  "  Not  found" 

?  CPflfe  ( 7 ) 

WAIT 
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^  SNDXF 

otherwise, warn  user  and  allow  another  try. 
CASE  .NOT.  FOUND () 

CT.gea 

§17,5  SAY  "There  is  no  "  ♦  sns 

24,5  SAY  "Press  any  key  to  try  again..." 

WAIT  "  " 

END CASE 

KNDDO( Continue  editing  until  user  requests  exit.) 

* — — -  Return  to  EDIT  menu. 

RETURN 


7.  DICT.PRG 


********************************************************************* 
*  MODULE  NAME  *  DICT.PRG 

AUTHOR  :  KIM,  SAM  NAM 

DATE  *  31  NOV  1986 

PURPOSE  :  This  program  allows  the  personnel  officer  to 

obtain  information  about  the  data  in  the  database. 

CALLED  BY  :  DRIVER 


MODULES  CALLED 


VARIABLES  USED: 
GLOBAL  :  i 


LOCAL 


today 

none 


A  problem  developed  as  we  used  the  DRIVER 
to  call  subprograms (too  many  files  open). 
This  program  is  the  main  driver  for  the 
dictionary  requests. 

holds  the  value  of  the  user  input, 
holds  date 


********************************************************************** 

CLEAR 

DO  WHILE  .T. 

CLEAR 

*  DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  do  forever. 

*  The  DO  WHILE  will  be  terminated  by  an  EXIT  command. 

*  Clear  the  screan  and  display  the  main  menu. 

DO  MENUS  CR 

@2,20  SAY  "DATA  DICTIONARY  INQUIRIES  " 

-  6,36  SAY  "SUBMENU" 

19,33  SAY  "INFORMATION" 

10.9  SAY  "A. What  is  ???  and  how  do  I  enter  it  into  the" 

10,53  SAY  "  computer?" 

11.9  SAY  "B.What  type  of  information  does  a  particular" 

11.55  SAY  "  file  contain?" 

12.9  SAY  "C.What  file  contains  a  particular  variable?" 

13.9  SAY  "D. Dictionary  information." 

14.9  SAY  "E. Change  date" 

15.9  SAY  "X.  Exit" 

20,8  SAY  "DATE  TIME" 

20.55  SAY  "UPDATED  BY" 

21,5  SAY  today 

E  21.19  SAY  TIMt() 

*9  21,52  SAY  gname 

9  23,10  SAY  "  [  Enter  selection  (  A  -  E,  or  X  to  Exit  )  :  «  ]" 

DO  WHILE  .T. 
i"0 

DO  WHILE  i»0 
i*INKEY ( ) 

~  21,19  SAY  TIME() 

23,54  SAY  "" 


4b 

i 


IF  U$PERjCHR(i))$"ABCDEX" 

ENDIF 

ENDDO 

?  23,54  SAY  UPPER (CHR( i) ) 

F  .MOT.  CHR(i)$"fie" 

EXIT 
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